Skip to main content

JS Linter — Check JavaScript Code Online

Free online JavaScript linter and code checker. Paste your JS to find var vs let/const mistakes, == vs ===, missing semicolons, leftover console.log, debugger, eval(), and unbalanced braces — instantly, 100% in your browser, nothing uploaded.

Lint your JavaScript

Paste code below and hit Lint code. Your code is never executed and never leaves this page.

Worked examples
Honest scope note: this is a heuristic linter, not a full parser like ESLint. It masks strings/comments and scans code patterns — fast and private, but it can miss context-dependent bugs and may flag valid code (the semicolon check is explicitly heuristic). It never executes your code.

Rules reference

All 12 checks the linter runs, with severities.

RuleSeverityWhat it catches

How to lint JavaScript online

  1. Paste your JavaScript into the editor above (or load a worked example).
  2. Click Lint code — or keep Live lint on to re-check as you type.
  3. Review issues by severity; click any issue to jump the cursor to its line.
  4. Filter with the severity chips, then Copy report to share the findings.

Frequently asked questions

Is this JS linter a replacement for ESLint?

No. This is a lightweight heuristic linter, not a full static analyzer like ESLint. It checks 12 common problem patterns (var usage, == vs ===, missing semicolons, console.log leftovers, debugger, eval(), unbalanced brackets, trailing whitespace, loose null checks, mixed quotes, unused variables) using fast pattern matching in your browser. ESLint parses a full AST with hundreds of configurable rules and understands scope, types, and project config — use ESLint for CI and team enforcement, and this tool for instant paste-and-check feedback.

What rules does the JavaScript linter check?

Twelve rules across three severities. Errors: debugger statements, eval() calls, with statements, and unbalanced braces/parens/brackets. Warnings: var instead of let/const, == / != instead of === / !==, possibly missing semicolons, leftover console.* calls, and trailing whitespace. Info: loose == null comparisons, mixed single/double quote styles, and declared-but-never-used variables. The full rule table with severities is listed on this page.

Why was valid code flagged for a missing semicolon?

The missing-semicolon check is explicitly heuristic. It flags lines that look like complete statements without a trailing semicolon, while skipping control-flow headers (if, for, while), lines ending in { } : or ,, arrow-function continuations, object properties, and lines followed by an ASI-hazard continuation like ( [ or .. A flagged line is still worth a glance — but if the code is intentional, ignore it. Heuristic hits are labeled as such in the message.

Is my JavaScript code uploaded to a server?

No. The entire linter runs locally in your browser as plain JavaScript — there are zero fetch or XHR calls on this page, which you can confirm in your browser developer tools network tab. Your code never leaves the page, so proprietary or sensitive scripts stay private.

Why doesn't the linter execute my code?

Executing pasted code would be a security risk and is unnecessary for linting. The linter only reads your source text: it masks strings and comments, then scans the remaining code for risky patterns and structural mistakes. Nothing you paste is ever run, eval'd, or passed to new Function().

How do I use the JS linter?

Paste your JavaScript into the editor (or load one of the 8 worked examples), then click "Lint code" — or enable live linting to re-check on every keystroke. Issues appear below grouped by severity with the exact line number; click any issue to jump the cursor to that line. Use the severity chips to filter errors, warnings, and info, and copy the report to share with your team.

What can this linter NOT catch?

It cannot catch logic bugs, type errors, undefined variables at runtime, async mistakes, or performance problems — those need real execution, tests, or a type checker like TypeScript. It also does not fully parse regex literals, so exotic regex syntax may confuse the bracket-balance check. Treat it as a fast first pass, not a proof of correctness.

Free tool by NRTechStudio