JavaScript Validator & Syntax Checker

What the JavaScript validator checks

This JavaScript validator parses your code with Acorn, the small, standards-focused JavaScript parser used inside many build tools. If the code cannot be parsed, you get the parser's message together with the exact line and column of the problem. If it parses, the report confirms there are no syntax errors and summarizes the file: number of lines, top-level statements, functions, and whether it was parsed as an ES module or a classic script.

Syntax errors are the errors that stop a script from running at all. In a browser, a single one means none of the code in that file executes, so checking before deploying, or before pasting a snippet into a CMS or tag manager, saves a lot of debugging.

Example: finding a missing parenthesis

function total(items) {
  let sum = 0
  for (const i of items {
    sum += i
  }
  return sum
}

Result:

Unexpected token (line 3, column 25)

Column 25 is the { right after items: the parser expected the closing ) of the for header first. Parser messages point to where the code stopped making sense, which is usually at or just after the real mistake.

Errors it catches

• Unbalanced brackets and braces, missing commas in object and array literals, unterminated strings and template literals.
• Invalid syntax such as const obj = { a: 1, b: 2 ; or a stray ,,.
• Early errors that the specification treats as syntax errors, such as redeclaring a let or const in the same scope (Identifier 'x' has already been declared).
• await inside a function that is not async, reported as an unexpected token at the expression after await.

What a syntax check does not catch

A file can be syntactically valid and still fail at runtime or contain bugs. This validator does not report:

• Undefined variables or typos in property names (documnet.title is valid syntax).
• Type errors such as calling a number as a function.
• Style or best-practice issues like unused variables, == instead of ===, or missing semicolons (automatic semicolon insertion makes most of those legal).
• Placement rules that depend on context. Like Prettier, the parser is configured leniently: a top-level return or an import inside a block is accepted, and code that is invalid as a module (for example with statements) is re-parsed as a classic script.

Those are the job of a linter such as ESLint, or of TypeScript's type checker. A good workflow is: validate syntax here for quick checks, and use a linter in your editor and CI for everything else.

Supported syntax

The parser accepts modern ECMAScript: classes and private fields, optional chaining, nullish coalescing, async/await, top-level await in modules, BigInt, and ES module import / export. JSX is accepted as well, so React components can be checked. TypeScript and Flow type annotations are not JavaScript and are reported as syntax errors: let a: number = 1 fails at the colon. For TypeScript, run the TypeScript Formatter, which parses TS and reports syntax errors.

Reading common error messages

After validation

Once the syntax is clean, tidy the code with the JavaScript Formatter or shrink it for production with the JavaScript Minifier. JSON is a separate format with stricter rules (no comments, double quotes only), so check it with the JSON Validator instead. Validation runs entirely in your browser; your code is not uploaded.