What Does Strict Mode Change?

Strict mode is a set of rules that you can switch on to remove the old loose behaviour from the language. You switch it on with a directive at the top of a file or at the top of a function body. The directive is the text use strict, alone in the statement position. Strict mode also applies on its own to every ES module, to the body of every class, and to the code inside every class method, so you do not need to write the directive in those places.

'use strict';

function report() {
  try {
    undeclared = 2;                 // ReferenceError in strict mode
  } catch (err) {
    console.log('strict mode:', err.name);
  }
}
report();

const frozen = Object.freeze({ a: 1 });
try {
  frozen.a = 2;                    // TypeError in strict mode
} catch (err) {
  console.log('frozen write:', err.name);
}

The changes fall into three groups. Assigning to a variable that was never declared throws an error instead of quietly creating a global. Writing to a property that cannot be written, such as an object that has been frozen, throws an error instead of failing quietly. And a set of syntax that was once tolerated, such as old octal numbers or the same parameter name used twice, becomes a parse-time error.

There are also changes to behaviour that are harder to notice. Deleting a property becomes an error when that property cannot be deleted. Arguments and parameters stop pointing at the same place, so changing a parameter no longer changes the matching argument. And the this value inside a plain function is no longer turned into the global object, which is the change most likely to break existing code when you switch a file over.

Why it matters in practice is simple. Strict mode turns a whole family of silent failures into loud errors that a test suite or a type checker can catch. It also lets the engine make stronger optimisations, because the engine no longer has to support the old loose behaviour.

The classic example is assigning to a name that was never declared. In loose mode the assignment quietly creates a property on the global object. In strict mode it throws a ReferenceError, because there is no variable to assign to.

function sloppyAssign() {
  undeclaredGlobal = 5;   // creates a global in loose mode
  return undeclaredGlobal;
}
console.log('sloppy:', sloppyAssign());   // 5

try {
  // The same statement inside a strict-mode eval throws instead.
  eval("'use strict'; undeclaredGlobal = 5;");
} catch (err) {
  console.log('strict:', err.name);      // 'ReferenceError'
}

The eval call is there so that both behaviours appear in one example you can run. Evaluating a string that contains a use strict directive makes that evaluated code strict, and the assignment then fails straight away. In a real strict file you would simply write the assignment at the top level and let the error travel upwards.

There are two more examples worth having ready. Old octal numbers such as 0755 are a syntax error under strict mode but still parse in loose mode, which is why old code with padded permissions sometimes breaks when a file is converted. And deleting a variable name is a syntax error under strict mode, where it used to do nothing at all and return false in loose mode.

There is a whole family of these cases. The pattern to recognise is that strict mode turns silent no-ops into errors, and that is exactly why teams switch it on. A bug that used to hide behind a failed assignment now shows up the first time the code runs.

In loose mode, calling a plain function with no receiver sets this to the global object. That means a stray check such as this === globalThis quietly succeeds, and the function can accidentally write to global state. Under strict mode the same call leaves this with no value at all, and reading it gives you no value instead of the global object.

'use strict';

function readThis() {
  return this;
}

console.log(typeof readThis());          // 'undefined' under strict mode
console.log(readThis() === globalThis);  // false

// A function created without the strict directive still gets the global object.
const sloppy = Function('return this;');
console.log(typeof sloppy());             // 'object'

// Methods keep their receiver even in strict mode.
const counter = { value: 7, read() { return this.value; } };
console.log(counter.read());              // 7

This is the change that breaks the most existing code when a team switches strict mode on. It is usually in code of the form var self = this;, which was used to capture a context. Those workarounds become unnecessary, and the captured value is now no value instead of the global object.

There are two clarifications that stop you from overstating it. Strict mode does not change how this is worked out for methods. Calling counter.read() still binds this to counter, and pulling the method out into a bare variable and calling it that way loses the receiver in both modes. And an arrow function never has its own this at all, in either mode, because it takes it from the scope around it. Strict mode only changes the default value that a plain function receives when there is no receiver.

The reason the change exists is safety. If a plain function relies on the global object as its context, that is very often an accidental tie that hides a bug in the way the function is called.