JavaScript Validator
Name The Line, Not Just The Error
This JavaScript validator parses a script the way an engine does and reports the first thing that stops it. Every note carries a line, a column and the token at fault, so you go straight there. Nothing you paste leaves the browser and nothing runs.
- FreePrice
- ES2024Parses
- NeverRuns code
- NoneUploads
JavaScript Validator
Read a script and name the first syntax error, with the line and the column
Nothing read yet.
Read to the end. Every line parses, and there is nothing to fix.
Ready. Paste a script, or press the sample button.
What A JavaScript Validator Checks
An engine reads a whole script before it runs a single line of it. Therefore one broken bracket anywhere stops the file, and the tab stays blank.
That is the failure this JavaScript validator exists for. It walks the script as text and reports the first place the grammar breaks, with the line and the column.
Alongside that it checks the shape of what it read. An unmatched brace, a string that never closes, a keyword used as a name, a stray comma inside a function call argument list.
It builds no execution context, so it creates no global and calls no function. Because the reader only reads the script, you can point a validator at code you would never run on a page of your own.
Nothing leaves this tab. Therefore a client script under an NDA gets read exactly like a public one.
How A JavaScript Validator Reads A Script
The first pass turns the text into tokens. A number, a string, a template literal, a regular expression, a name, an operator and a keyword are all different things, and the reader decides which it is looking at one character at a time.
Then the second pass walks those tokens in order and checks the shape of what it reads: which brackets are still open, which names a scope already holds, and whether a word such as return has a function around it. The rulebook here is ECMA-262, the standard behind every engine.
The order matters, and it explains a surprising number of error messages. Because tokenising runs first, a script that a reader thinks has a bracket problem may really have a quotation mark that never closed.
One case needs a second look rather than a rule: a slash is a division operator or the start of a regular expression, and the answer depends on the token before it. So the tokeniser asks the last token what it was.
Template literals add one more wrinkle. Because a template can hold an expression inside braces, the tokeniser keeps a stack of the template it is inside. So a brace in a string is text, and a brace inside a template is code.
Why A Valid Script Can Still Be Wrong
Grammar and meaning are separate layers. A validator answers the grammar question, and every useful one stops there.
So a script can pass with a variable that is never declared in strict mode, a property read from a value that holds undefined at that moment, or an await inside a function that is not asynchronous. Each of those is a runtime problem.
The line between them is worth holding on to. A syntax error means no part of the file ran, and a runtime error means the file ran until that line. The two call for completely different debugging.
That is also why this page names the first error rather than a hundred. Because the parse stops there, everything after it is guesswork, and a list of guesses is worse than one fact.
The Six Checks, And What Each One Means
The first check is bracket balance. The reader reports a brace, a bracket or a parenthesis without a partner at the point it gave up. This is the one failure that can cost the whole file.
The second is an unclosed string or template. Because the tokeniser swallows everything after an opening quote, the note names both the quote and the end of the file where the search stopped.
The third is a token the grammar does not allow. Two operators in a row, a comma in the wrong place, or an arrow with nothing before it. Each one comes with the token itself.
The fourth is a keyword misused as a name. The reader refuses an assignment to a reserved word, and a variable named with one, before anything runs.
The fifth is a duplicate in one scope. Two parameters with the same name, or a let that repeats a name already declared in the same block. Because the later one wins in the first case and throws in the second, the reader names both.
The sixth is a return outside a function, and its relatives. A break with no loop, a case with no switch, and a yield with no generator. Those belong in one position and nowhere else.
What This Page Will Not Do
It will not run your script. Nothing here creates a function, sets a variable or starts a timer, so nothing can act on the page while you read it.
It will not report a runtime error, a type error or a failed network call. Those need an engine, and an engine is what you already have in the browser tab next door.
It will not fix the code. A guess at the missing bracket is a note, not an edit, because an automatic fix can turn a clear error into a quiet behaviour change.
It will not check types. A file with a type annotation on it carries more than JavaScript, so paste the output of your compiler rather than its input.
How To Use The JavaScript Validator
Four steps, and none of them need an account.
- 1
Paste the script
So paste a whole file or one function. Because the reader works on text rather than a compiled form, a fragment is fine as long as its brackets balance.
- 2
Pick the source type
Then choose a script or a module. Because import and export belong to a module, that choice decides whether the reader reads them as valid or as a fault.
- 3
Read the first note
Next, go to the line and column it names. Because the parse stops at the first failure, the second note is a consequence rather than a second mistake.
- 4
Fix, re-run, then carry on
Finally, edit in your own editor and paste it back to confirm the count is zero. After that, the file is ready for the minifier or for the browser.
Why Use This JavaScript Validator
Five reasons, and each one saves a debugging session.
It names a line and a column
Because the note carries both, you land on the character rather than on the area. So a two hundred line file is a short read rather than a hunt.
It explains why the parse stopped
A note says what the grammar expected at that point. Therefore the fix is usually clear from the note alone, without a second opinion.
Nothing executes
Because the script is only read, a snippet from a stranger cannot act while you look at it. So a validator is the safe place to paste one.
Nothing uploads
The parse happens here and nowhere else. Hence a file from a private repository is safe to paste.
It reads modern syntax
Since the grammar follows the current standard, an arrow function, an optional chain and a class field all parse. So a modern file is not flagged for being modern.
Habits That Keep A Script Parsing
Six habits that keep a script easy to read and quick to validate.
- Close the bracket as you open it So the partner is already there when you fill the middle in. It is a small habit that removes the most expensive class of syntax error.
- Write in strict mode A module is strict by default, and a script can ask for it with a directive on the first line. Because strict mode turns several silent mistakes into errors, your engine stops on them rather than carrying on quietly.
- Prefer const, then let A var declared inside a block belongs to the function, which is where accidental reuse hides. Therefore two names that look separate can be one name.
- Keep one statement per line An engine inserts semicolons where they are missing, and it does not always guess how you meant it. Because one line per statement removes the ambiguity, the reader never has to guess.
- Validate before you minify A minifier trusts its input, so a broken script comes out broken and harder to read. Hence check the readable file first, where the line numbers mean something.
- Paste the compiled output A type annotation is not JavaScript, so a file with one will not parse. Therefore run the compiler first and check what it emitted.
Six Ways A Script Fails To Parse
Each of these stops the whole file, which is why none of them is easy to miss once it happens.
A bracket closed in the wrong order
Watch out here. An engine sees a pair that does not match rather than a missing mark, so the note points at the wrong-looking line rather than the wrong one.
A quote inside a string of the same kind
A quote that is not escaped ends the string early. Because the tokeniser then reads the rest as code, the error appears many lines later than the mistake.
A slash that means division
Two lines down from a missing semicolon, a slash can start a regular expression instead of dividing. Hence one missing mark turns into a confusing error about a pattern.
A template that is never closed
A backtick left open swallows the rest of the file. So the note names the opening backtick and the end of the input rather than the line you meant to fix.
A comma where a semicolon belonged
Inside an object a comma is right and inside a block it is wrong. Because the two look alike at a glance, this one survives a careful read.
A keyword used as a name
Something called class or default parses in one position and not another. Therefore a name that worked in one file can be an error in the next.
JavaScript Validator Questions
Is this JavaScript validator free?
Yes. There is no account, no limit and no paid tier. So you validate as many scripts as you like.
Does it run my code?
Never. The reader takes the script as text and parses it, and calls no function. So a snippet from a stranger cannot act while you look at it.
What does it check?
Six families: bracket balance, unclosed strings and templates, tokens the grammar refuses, reserved words used as names, duplicates in one scope, and misplaced return, break or yield.
Which version of JavaScript does it accept?
The current standard, up to ES2024. So an arrow function, an optional chain, a class field and a top-level await in a module all parse.
Does it find runtime errors?
No. A runtime error needs an engine to run the code, and that is a different job. This page answers the grammar question only.
Why does it report only one error?
Because the parse stops at the first failure. Everything after that point is a guess, and one fact is more useful than a hundred guesses.
Is my script uploaded anywhere?
No. The whole check runs in this browser tab. So a script under a confidentiality clause stays where it is.
Can I validate a fragment rather than a whole file?
Yes. A single function works as long as its brackets balance. The line numbers then refer to the lines you pasted.
Does it understand JSX or TypeScript?
Not directly, because those are extensions rather than JavaScript. So run the compiler first and validate what it emits.
What is the difference between a syntax error and a type error?
A syntax error means no part of the file ran. A type error happens at runtime, on a line that parsed. The two call for different debugging.
Does it check browser support?
No. A statement can be valid and still do nothing in the browser that matters. Grammar and support are separate questions.
Can it fix the error for me?
No, and that is deliberate. An automatic fix can turn a clear error into a quiet behaviour change, which is harder to find than the note was.
Why is my code flagged for a slash?
A slash is division or the start of a regular expression, and the answer depends on the token before it. Without a semicolon in the right place the reader has to pick one, and the note says which.
Does it work with a module?
Yes. Choose the module source type and import and export become valid, while a plain script reads both as an error. A module also treats let, static and yield as reserved, so a name that passes in a script can fail here.
Can I validate a minified file?
Yes, though the line numbers are far less useful. Because a minified file is usually one long line, go back to the readable source for the fix.
Does it count anything?
Yes. The summary reports lines, tokens and characters, which is useful when you are checking whether a paste lost something at the end.
Is it the same as a linter?
No. A linter names style problems and unused variables, which a parser does not care about. So a clean result here means it parses, and nothing more.
Does it work on a phone?
Yes. The panes stack and the notes wrap. So you can run a quick check from a phone, though a long file is easier on a keyboard.
Can I download the notes?
Yes. The download writes the notes to a text file, which is handy when a ticket needs the exact line numbers.
Do I need an account or an extension?
No. There is no sign-up, no plugin and no extension to add. So you close the tab once the script parses.
Tools That Go With This One
Four pages the same job usually leads to.
JavaScript minifier
Once the script parses, take the whitespace and comments out. Because a browser downloads every byte, minify after validating rather than before.
Open tool →Code beautifier
A file that parses can still read badly. So reindent it and settle the brace style before the next review.
Open tool →JSON formatter
Most script failures here come from data rather than logic. So unfold the payload and check it parses too.
Open tool →CSS validator
The other half of a front-end build. Because the browser drops a declaration with a typo in silence, that sheet deserves the same check.
Open tool →
Find The Line The Engine Would Refuse
Paste the script, read the first note, fix it and run it again. Nothing executes and nothing uploads. Most files parse before the kettle boils, and the note tells you which character to look at.