JavaScript Validator
Check JavaScript source for syntax errors instantly, entirely in your browser.
Valid JavaScript, no syntax errors.
Valid JavaScript — no syntax errors found (script mode).
Stats
How the JavaScript Validator works
This tool checks JavaScript source for syntax errors by asking your browser's own JavaScript engine to parse the code (without ever executing it), using the same grammar engine that runs your web pages. That means the syntax errors reported here — unexpected tokens, unterminated strings, missing brackets, invalid declarations — are exactly what the browser would throw when it tries to load your script. A supplementary bracket and quote scanner cross-checks braces, parentheses, and string literals line-by-line so you can jump straight to unbalanced tokens even when the engine only reports an end-of-input error.
Use Script mode for regular JavaScript files, inline <script> tags, or CommonJS/Node code. Use Module mode when your snippet contains ES module syntax like import or export statements. Nothing you paste here ever leaves your browser — all parsing happens locally and instantly.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Getting a line and column for a syntax error a build reported without one.
- Checking a snippet before pasting it into a file.
- Confirming a paste was not truncated mid-expression.
- Checking whether a file parses as the module type you expect.
- Reviewing a snippet from an untrusted source before running it.
Frequently Asked Questions
- What does a validator catch that a linter does not?
- Syntax errors — code that cannot be parsed at all. A linter operates on a parsed AST, so it needs valid syntax before it can say anything. That is why a file with a missing brace produces one parse error and no lint output whatsoever.
- Why does a missing semicolon usually not matter?
- Automatic semicolon insertion. The parser inserts one where a newline would otherwise cause an error, which covers most cases — and fails on the ones that begin with `(`, `[`, `` ` ``, `+` or `-`, where the next line is read as a continuation instead.
- What is the classic ASI failure?
- A `return` with its value on the next line. `return` followed by a newline gets a semicolon inserted immediately, so the function returns `undefined` and the value below it is unreachable — valid syntax, no error, completely wrong behaviour.
- Does strict mode change what is valid?
- Yes. It turns silent failures into errors — assigning to an undeclared variable, duplicate parameter names, `delete` on a plain identifier, octal literals. Modules and class bodies are always strict, which is why the same code can behave differently in two files.
- Why does my valid file fail to parse?
- Usually a syntax version mismatch. JSX, TypeScript annotations, decorators and top-level `await` all need a parser configured for them, and a plain ECMAScript parser rejects them as syntax errors even though the toolchain builds them fine.
Common errors and gotchas
- Confusing a syntax check with a lint, which catches entirely different classes of problem.
- Validating module syntax as a script, or the reverse, where `import` is legal in only one.
- Expecting type errors to surface, which parsing cannot see.
- Assuming a parse means it runs, when a runtime error is a separate matter.
- Validating transpiled output when the source was the thing with the problem.