eval & new Function

A string that runs as code

Most JavaScript comes from a file or a <script> tag. The browser reads that code before it runs it.

eval and new Function work differently. They take a string, which is just text, while the program is already running. Then they ask the JavaScript engine to read that text as code and run it. The engine is the part of the browser that runs JavaScript.

Running text as code changes some rules. It changes which variables the code can see. This is called its scope. It also affects closures, strict mode, browser security, and speed. This lesson shows what really happens. Then it shows how to do the same jobs without code strings, using plain data and functions you already wrote.

There are two kinds of eval call:

• Direct eval is a call written exactly as eval(...), where the name eval still means JavaScript's built-in eval. The string runs inside the function that made the call, so it can read that function's local variables.
• Indirect eval is any other way to call the same built-in eval. The string runs as global code, so it sees only global names. Global names are the ones every script on the page can see.

Each of these calls is indirect:

• a second name for eval, like const indirect = eval, then indirect(...)
• the comma trick (0, eval)(...)
• the optional call eval?.(...)
• a property read like globalThis.eval(...)

1globalThis.name = "global name";2function readName() {3  const name = "local name";4  const indirect = eval;5  return [eval("name"), indirect("name"), (0, eval)("name")];6}7console.log(readName().join(" | "));

Line 1 puts a global name on globalThis, the object that holds global names. Line 3 makes a local name inside readName. Line 4 makes indirect, a second name for eval.

Line 5 calls eval three ways. The program prints local name | global name | global name. Only the first call, written exactly as eval(...), finds the local name.

1function chooseRunner() {2  const eval = (text) => "not JavaScript: " + text;3  return eval("1 + 1");4}5console.log(chooseRunner());

Line 2 makes a local function that is also named eval. It only joins two strings. Line 3 calls that local function, not the built-in eval, so the program prints not JavaScript: 1 + 1.

So direct eval needs two things: the call is written eval(...), and the name eval means the built-in eval. This example only runs in sloppy mode, the older mode without "use strict". Strict mode does not allow a variable named eval.

1function readX() {2  const x = "local x";3  return eval("x");4}5console.log(readX());Run

(0, eval)("x") looks odd, but people write it on purpose to get indirect eval. The comma runs both sides and gives back the right side: the eval function itself. The call then uses that function value, not the name eval, so it is not direct.

The lab below runs four fixed snippets inside a sandboxed iframe. An iframe is a small page inside this page. Sandboxed means it is kept apart, so its code can't touch this lesson. Press a button to run one snippet and see the real result.

1const cases = {2  direct: 'function read(){ const x = "local x"; return eval("x"); } read();',3  indirect: 'globalThis.x = "global x"; function read(){ const x = "local x"; return (0, eval)("x"); } read();',4  sloppyVar: 'function read(){ eval("var leaked = 1"); return typeof leaked; } read();',5  strictVar: 'function read(){ "use strict"; eval("var hidden = 1"); return typeof hidden; } read();'6};7addEventListener("message", (event) => {8  if (!event.data || event.data.lesson !== "eval" || !(event.data.caseId in cases)) return;9  try {10    const value = eval(cases[event.data.caseId]);11    parent.postMessage({ lesson: "eval", caseId: event.data.caseId, status: "ok", value: String(value) }, "*");12  } catch (error) {13    parent.postMessage({ lesson: "eval", caseId: event.data.caseId, status: "error", value: error.name + ": " + error.message }, "*");14  }15});

Direct eval can also make new variables. What happens to a var made inside it depends on the mode:

• In sloppy mode, the var is added to the function that called eval. It leaks out.
• In strict mode, direct eval keeps its own set of variables. The var is gone when eval ends.

1function sloppy() {2  eval("var leaked = 1");3  return typeof leaked;4}5function strict() {6  "use strict";7  eval("var hidden = 1");8  return typeof hidden;9}

typeof gives the type of a value as a string. For a name that doesn't exist, it gives "undefined" instead of an error.

In the lab above, the sloppy case gives "number": leaked still exists after eval, so line 3 finds it. The strict case gives "undefined": hidden stayed inside eval, so line 8 can't find it.

1function readVar() {2  "use strict";3  eval("var inside = 1");4  return typeof inside;5}6console.log(readVar());

Line 2 turns on strict mode for the function. Line 3 makes inside, but only inside eval. Line 4 can't see it, so line 6 prints undefined.

Strict mode makes eval a little tidier. It does not make running a code string safe.

new Function builds a new function from strings. Every string except the last one is a parameter name. The last string is the body: the code inside the function. For example, new Function("a", "b", "return a + b") makes a function that adds a and b.

1globalThis.shared = 7;2const add = new Function("a", "b", "return a + b");3function makeSecretReader() {4  const secret = 10;5  return new Function("return secret");6}7const readSecret = makeSecretReader();8const readShared = new Function("return shared");9console.log(add(2, 3));10try { console.log(readSecret()); }11catch (error) { console.log(error.name); }12console.log(readShared());

Line by line:

• Line 2 makes add with two parameters, so line 9 prints 5.
• Lines 3 to 6 make a local secret and build a function that tries to read it. That function can't see secret. So line 10 throws, and line 11 prints ReferenceError, the error for a name that doesn't exist.
• Line 8 builds a function that reads the global shared, so line 12 prints 7.

1const cases = {2  add: () => new Function("a", "b", "return a + b")(2, 3),3  closure: () => { const secret = 10; return new Function("return secret")(); },4  global: () => { globalThis.shared = 7; return new Function("return shared")(); }5};6addEventListener("message", (event) => {7  if (!event.data || event.data.lesson !== "eval-new-function" || !(event.data.caseId in cases)) return;8  try { parent.postMessage({ lesson: "eval-new-function", caseId: event.data.caseId, status: "ok", value: String(cases[event.data.caseId]()) }, "*"); }9  catch (error) { parent.postMessage({ lesson: "eval-new-function", caseId: event.data.caseId, status: "error", value: error.name + ": " + error.message }, "*"); }10});

1const sloppy = new Function("return typeof this");2const strict = new Function('"use strict"; return typeof this');3console.log(sloppy());4console.log(strict());

Both functions are made from strings. Inside a function, this is the object the function is working on. A sloppy function called on its own gets the global object as this, so line 3 prints object. The second body starts with "use strict", so its this stays undefined and line 4 prints undefined.

So a body made by new Function is sloppy unless the string itself starts with "use strict". Being inside a strict file does not change that. Like eval, new Function can be blocked by a browser rule called CSP. The next section explains it.

The biggest problem with eval is security. Suppose some text from a visitor ends up inside an eval string. Now the visitor isn't just giving you a value. They are writing code that runs on your page, with everything your page can reach. This attack is called code injection.

Browsers have a guard against it: a Content Security Policy, or CSP. A CSP is a list of rules that a site sends with its page. The script-src rule says which scripts may run. Unless that rule includes unsafe-eval, the browser refuses to turn strings into code. Many real sites leave unsafe-eval out.

1<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline'">2<script>3try {4  const value = eval("21 * 2");5  parent.postMessage({ lesson: "eval-csp", status: "ok", value: String(value) }, "*");6} catch (error) {7  parent.postMessage({ lesson: "eval-csp", status: "error", value: error.name + ": " + error.message }, "*");8}9</script>

In Chrome, the blocked frame throws an EvalError. The message after the error name is different in each browser, so code should not depend on it. The same rule also blocks:

• new Function
• setTimeout or setInterval called with a string instead of a function

1let message = "waiting";2const update = () => { message = "ready"; };3const runLater = (callback) => callback();4runLater(update);5console.log(message);

Line 2 stores a function in update, not a string of code. Line 3 makes runLater, a stand-in for a timer: it takes a function and calls it. Line 4 hands it update, so no text has to become code. Line 5 prints ready.

With a real timer, write setTimeout(update, 1000), not setTimeout("update()", 1000).

Most of the time, people reach for eval to do one of three ordinary jobs. None of them needs a code string:

• read data, like JSON text from a server
• pick one action from a set of known actions
• turn text, like a page number, into a simple value

1const data = JSON.parse('{"score":42}');2const formatters = { upper: (text) => text.toUpperCase() };3const key = "upper";4const page = new URLSearchParams("?page=2");5console.log(data.score);6console.log(formatters[key]("safe"));7console.log(Number(page.get("page")));

Line 1 reads JSON text as data. Lines 2 and 3 keep a function in an object and pick it with a key. Line 4 reads a URL query string, the part after ?. The last three lines print 42, SAFE, and 2.

• For data from a server or from storage, use JSON.parse. JSON is a text format for data.
• To pick known behavior with a key, use an object, a Map, or a switch statement.
• For URL or form values, read them with URLSearchParams, turn text into a number with Number(), and check that the value makes sense.

1const actions = {2  greet: (user) => "Hello, " + user,3  count: (cart) => String(cart.length),4};5const action = "greet";6console.log(actions[action]("Asha"));

Lines 1 to 4 list the only actions the page supports. An object used like this is called a lookup table: you look up a key and get back a value. Line 5 holds the chosen action as a plain string. Line 6 looks up that key, calls the function it finds, and prints Hello, Asha.

If the key isn't in the table, you can stop before anything runs.

1const rawPage = new URLSearchParams("?page=oops").get("page");2const page = Number(rawPage);3console.log(Number.isInteger(page) && page > 0 ? page : 1);

Line 1 reads the text "oops" from the URL. Line 2 tries to turn it into a number and gets NaN, which means "not a number". Line 3 checks for a whole number above 0. NaN fails that check, so line 3 prints 1, the first page.

The check shows clearly which input the page accepts.

1function addTwoNumbers(text) {2  const parts = text.split("+").map((part) => part.trim());3  if (parts.length !== 2 || parts.some((part) => part === "" || Number.isNaN(Number(part)))) {4    throw new Error("Use two numbers separated by +");5  }6  return Number(parts[0]) + Number(parts[1]);7}8console.log(addTwoNumbers("2 + 5"));

A parser is code that reads text and checks that it follows exact rules. This one accepts exactly two numbers with a + between them.

• Line 2 splits the text at + and trims the spaces from each part.
• Line 3 checks for exactly two parts that are both numbers. If not, line 4 throws an error.
• Line 6 adds the two numbers, so the last line prints 7.

Text like alert(1) is rejected. It never runs, and it can't reach the page's variables.

The speed cost of eval

Engines make code fast by studying it before it runs. For example, they work out which variables each function reads and writes.

Direct eval spoils that study. The string might read any local name, or make a new var in sloppy mode. So the engine has to play safe and skip some speed-ups for that function.

There is also extra work while the page runs. Normal code is read once, when the script loads. An eval string, or a new Function body, is read and turned into runnable code when that line runs. How long that takes depends on the browser, the device, and the code, so this lesson gives no single number.

Running the same eval in a loop repeats the risk, and it may repeat that work too. A normal function, a lookup table, or a small parser has a fixed shape that the engine can study. It also lets you check input before you act on it. Measure speed with real work only after you have the safer design.

Where you will use this

You will rarely write eval in your own app. But you will review code that uses it. Look for code strings during security reviews, when a site adds a CSP, and when a bug comes from a variable that seems to appear from nowhere.

Each row below is one way to run text as code, or a safer tool. Read across a row to see what it can reach and what it is for.

If you build a teaching tool, a rules engine, or a formula box, write a small parser for just the language you need. If you truly must run JavaScript, keep it apart from the page, as in the Windows, iframes & postMessage lesson:

• run it in a sandboxed iframe
• run only fixed or trusted code
• stop it if it runs too long, where you can
• check every message it sends back

A parser is not the same as eval. It accepts only the text your feature needs, like numbers and + for a tiny calculator. It gives back a value and never gets access to the page's variables. That makes it easier to check for safety, and it can give clear error messages.

Common misconceptions

Key takeaways

• Direct eval is a call written exactly as eval(...). It can see the local variables of the function that called it.
• Indirect eval and new Function see only global names. new Function can't see the local variables where it was made.
• In strict mode, a var made inside direct eval stays inside. In sloppy mode, it leaks out.
• A CSP without unsafe-eval blocks eval, new Function, and timers given strings.
• Use JSON.parse, lookup tables, URLSearchParams, input checks, and normal functions instead.

Up next: Higher-order functions.