Automatic Semicolon Insertion (ASI) in JavaScript Explained

Automatic Semicolon Insertion (ASI) is a feature of the JavaScript parser that automatically adds semicolons at certain points during code parsing. It allows developers to omit semicolons in most situations without causing syntax errors. However, ASI follows specific rules defined in the ECMAScript specification, and a small number of edge cases can produce unexpected behavior. Understanding these rules is essential whether you write semicolons explicitly or leave them out.

ASI is not a runtime feature. It operates during the parsing phase, before any code executes. The parser reads your source code, and when it encounters a spot where a semicolon is needed but missing, it inserts one based on a set of deterministic rules. Think of it as a helpful proofreader that adds punctuation to your sentences, but one that occasionally misreads your intent.

The Three ASI Rules

The ECMAScript specification defines three rules for when the parser inserts a semicolon. Every instance of ASI in your code is governed by one of these rules.

Rule 1: Line Terminator Before Invalid Token

When the parser reads code left to right and encounters a token that is not allowed by the grammar, it checks whether a line terminator (newline) appears between the previous token and the offending token. If yes, it inserts a semicolon before the offending token:

javascript

// What you write:
let a = 1
let b = 2
 
// What the parser sees:
// "let a = 1 <newline> let b = 2"
// After "1", the next token is "let", which is invalid in this context.
// A newline exists between "1" and "let", so ASI inserts a semicolon:
let a = 1;
let b = 2;

This is the most common ASI rule and handles the vast majority of cases where you omit semicolons.

javascript

// Another example:
const name = "Alice"
console.log(name)
 
// Parser encounters "console" after "Alice" across a newline.
// "console" is not valid after a string literal, so ASI inserts:
const name = "Alice";
console.log(name);

Rule 2: Before the Closing Brace

When the parser encounters a closing brace }, and the previous token does not already have a semicolon, ASI inserts one:

javascript

// What you write:
function greet() { return "hello" }
 
// ASI inserts a semicolon before the closing brace:
function greet() { return "hello"; }

javascript

// This is why block bodies work without semicolons:
if (true) { doSomething() }
// Becomes:
if (true) { doSomething(); }

Rule 3: After Certain Restricted Tokens

Some JavaScript statements have "restricted productions," meaning no line terminator is allowed between certain tokens. If a line terminator appears in a restricted position, ASI inserts a semicolon immediately after the restricted token.

The restricted tokens are: return, throw, break, continue, yield, and the postfix ++/-- operators.

javascript

// DANGER: return with value on next line
function getObject() {
  return
  { name: "Alice" }
}
// ASI inserts semicolon after "return":
// return;
// { name: "Alice" }
// Result: returns undefined, not the object
 
// FIX: start the value on the same line as return
function getObject() {
  return {
    name: "Alice"
  };
}

ASI Rule Summary Table

Where ASI Fails: The Dangerous Edge Cases

ASI works correctly in the vast majority of situations. The following cases are the known exceptions where ASI creates bugs:

Lines Starting with (

javascript

const result = getValue()
(function() {
  console.log("IIFE")
})()
 
// Parser reads: getValue()(function() { ... })()
// It treats the IIFE as an argument to getValue()'s return value
// Result: TypeError if getValue() doesn't return a function

The parser sees no reason to insert a semicolon after getValue() because ( is a valid continuation (function call). Rule 1 only fires when the next token is invalid, and ( is perfectly valid after an expression.

Lines Starting with [

javascript

const greeting = "hello"
["world", "earth"].forEach(w => console.log(w))
 
// Parser reads: "hello"["world", "earth"].forEach(...)
// It treats ["world", "earth"] as property access on "hello"
// The comma operator evaluates to "earth"
// "hello"["earth"] is undefined
// Result: TypeError: Cannot read properties of undefined

Lines Starting with Template Literals

javascript

const tag = "div"
`<${tag}>Hello</${tag}>`
 
// Parser reads: "div"`<${tag}>...`
// It treats this as a tagged template literal
// "div" is called as a tag function
// Result: TypeError: "div" is not a function

Lines Starting with /

javascript

const a = 1
/regex/.test("string")
 
// In theory, this could be read as: 1 / regex / .test("string")
// In practice, most engines correctly parse this because they
// track whether / starts a regex or division based on context.
// However, this edge case exists in the specification.

Lines Starting with + or -

javascript

const a = 1
+b
 
// Could be read as: 1 + b (addition)
// Or as: 1; +b (two statements, unary plus)
// ASI does NOT insert because + is a valid continuation
// Result: 1 + b (probably not what you intended)

ASI and Restricted Productions in Detail

return

javascript

// ASI inserts after return
function bad() {
  return
    42
}
bad() // undefined
 
// No ASI because value starts on the same line
function good() {
  return 42
}
good() // 42
 
// Wrapping in parentheses: value starts on the same line as return
function alsoGood() {
  return (
    42
  )
}
alsoGood() // 42

throw

javascript

// ASI inserts after throw, causing a SyntaxError
// because throw requires an expression
throw
  new Error("fail")
// SyntaxError: Illegal newline after throw
 
// FIX: keep on the same line
throw new Error("fail")

break and continue

javascript

// Labels with break or continue must be on the same line
outer: for (let i = 0; i < 3; i++) {
  for (let j = 0; j < 3; j++) {
    break
      outer  // ASI inserts after "break", so "outer" is unreachable
  }
}
 
// FIX: keep label on the same line
outer: for (let i = 0; i < 3; i++) {
  for (let j = 0; j < 3; j++) {
    break outer
  }
}

Postfix ++ and --

javascript

let a = 1
let b = 2
 
// What you might expect:
a
++b
// You might expect: a; ++b (a stays 1, b becomes 3)
 
// What actually happens:
// Rule 1 alone would NOT insert a semicolon because ++
// is a valid continuation of the expression "a".
// However, Rule 3 (restricted production) overrides this:
// postfix ++ cannot have a line terminator before it,
// so ASI inserts a semicolon after "a".
// Result: a; ++b; (a = 1, b = 3)

How Formatters and Linters Handle ASI

Modern tooling eliminates most ASI-related bugs automatically:

Prettier

Prettier reformats your code according to its rules. With "semi": true (the default), it adds semicolons everywhere. With "semi": false, it removes them but adds defensive semicolons where needed:

javascript

// Input (no semicolons, dangerous pattern):
const x = 1
[1, 2, 3].map(n => n * 2)
 
// Prettier output with "semi": false:
const x = 1
;[1, 2, 3].map(n => n * 2)
// Prettier adds the defensive semicolon automatically

ESLint

The no-unexpected-multiline rule detects lines where ASI might produce unexpected behavior:

javascript

// ESLint flags this with no-unexpected-multiline:
const fn = getValue()
(async () => {
  // ...
})()
// Warning: Unexpected newline between function call and argument list

Tool Configuration Comparison

Testing ASI Behavior

You can verify how ASI works by testing in the browser console or Node.js REPL:

javascript

// Test 1: Does ASI insert after a variable declaration?
let a = 1
let b = 2
console.log(a, b) // 1 2 (ASI works correctly)
 
// Test 2: Does ASI handle the return trap?
function test() {
  return
  { value: 42 }
}
console.log(test()) // undefined (ASI inserted after return)
 
// Test 3: Does ASI handle the ( danger?
const x = 1
const fn = function() { return 2 }
// If the above two lines were:
// const x = fn()
// (function() { console.log("test") })()
// You would see the bug

Best Practices

Always start return values on the same line. This is the most impactful ASI rule to internalize. Whether you use semicolons or not, never place a return value on a new line. Start it on the return line and wrap multi-line values in parentheses if needed.

Use a formatter that understands ASI. Prettier automatically handles defensive semicolons when configured for the no-semicolon style. Do not rely on human discipline to catch ASI edge cases; let the machine handle it.

Enable no-unexpected-multiline in ESLint. This rule is your safety net. It catches the (, [, and template literal edge cases at lint time instead of runtime. Enable it regardless of your semicolon preference.

Learn the three rules, not just the edge cases. Memorizing "never start a line with (" is useful but brittle. Understanding the three ASI rules makes you capable of reasoning about any new situation you encounter, including patterns not covered in tutorials.

Use consistent line-break placement in expressions. When breaking long expressions across multiple lines, start the continuation with an operator rather than ending the previous line with one:

javascript

// Preferred: operator at start of continuation (ASI-safe)
const result = longVariableName
  + anotherLongVariable
  + yetAnotherVariable
 
// Risky: operator at end of line
const result = longVariableName +
  anotherLongVariable +
  yetAnotherVariable
// This works but can be confusing when reading quickly

Common Mistakes and How to Avoid Them

Putting return value on the next line. This is responsible for more ASI bugs than any other pattern. The fix is simple: always start the value on the return line and use parentheses for multi-line values.

Assuming ASI always inserts semicolons at newlines. ASI only inserts when the next token after a newline would cause a syntax error. If the next line starts with (, [, `, /, +, or -, the parser may see it as a valid continuation of the previous expression.

Relying on ASI without a formatter. If you choose the no-semicolon style, not using Prettier is risky. Manual code entry is error-prone, and the edge cases are easy to miss in code review. Always pair the no-semicolon style with an automated formatter.

Confusing ASI with optional semicolons. ASI is not the same as "semicolons are optional." Semicolons are part of the grammar. ASI is a parser feature that inserts them when certain conditions are met. The distinction matters because ASI has specific rules that fail in specific situations.

Not understanding the restricted production rule. Developers often know about the ( and [ dangers but forget that return, throw, break, and continue also have ASI restrictions. The restricted production rule applies to a specific set of keywords, and all of them should be followed by their expression on the same line.

Next Steps