Summary

This free ai code reviewer is a rule-based pre-review checker. Paste a git diff or a snippet and it scans the added lines against thirteen rules covering hardcoded secrets, string-built SQL, swallowed exceptions, disabled tests and debug leftovers. It also flags oversized changes and missing tests, then returns a 0-100 score with line-numbered findings. It runs entirely in your browser, uses no AI model, and is meant to clear the mechanical issues before a human reviews.

Check Your Diff Before a Reviewer Does

Paste a git diff or a snippet. This free ai code reviewer flags secrets, unsafe SQL, swallowed errors, leftover debug code and oversized changes in your browser, and gives the pull request a score out of 100.

Check my diff
Engineer reviewing a side-by-side code diff on a monitor

Pre-review diff checker

Paste a unified diff or any code. Only added lines are checked when a diff is detected. Nothing you paste leaves your browser.

--/100
Paste code to start
Nothing checked yet.
    How it works

    What the checker looks at, and what it ignores

    Added lines only

    If you paste a unified diff, the checker reads the hunk headers, counts line numbers in the new file, and scans only the lines you added. Removed lines and unchanged context never produce a finding, so you are not blamed for old code.

    Severity-weighted score

    Thirteen rules sit in three tiers. High costs 15 points: hardcoded secrets, eval, string-built SQL, disabled TLS checks. Medium costs 7: swallowed exceptions, focused tests, innerHTML, a 400-line diff. Low costs 2: TODOs, debug prints, commented-out code. Each rule counts at most three times.

    Size and test checks

    Past 200 added lines you get a nudge to split the change, past 400 a firmer one. That follows the SmartBear Cisco finding that review quality drops once a reviewer faces more than 200 to 400 lines at a time. A diff over 50 added lines with no test file is flagged too.

    Using it

    From paste to a clean pull request in four moves

    1. 1

      Paste your diff

      Run git diff main...HEAD, or git diff --staged before you commit, and paste the output. A plain snippet works too, but you lose file names and test-file detection.

    2. 2

      Read the high findings first

      Red items are the ones a reviewer will stop on. A hardcoded key in a commit stays in history even after you delete the line, so rotate it, do not just remove it.

    3. 3

      Fix or justify the rest

      Each finding comes with a one-line fix. If a flag is a false positive, say so in the PR description. That saves the reviewer the same question.

    4. 4

      Copy the checklist

      The copy button turns the findings into a markdown checklist you can paste into the PR body, so the reviewer sees what you already caught.

    Why a pre-check

    The first thirty seconds of a review should not be spent on console.log

    Open a pull request from a colleague and you know the routine. You scroll the diff, spot a leftover debug print, a TODO with no ticket, a skipped test, and a catch block that swallows the error. None of that needs a human. It needs a checklist that runs before the request goes out. That is the gap this tool fills. A reviewer's attention is limited: the SmartBear study of Cisco reviews found defect discovery holds up when people review 200 to 400 lines in 60 to 90 minutes, and degrades beyond that. Every minute spent on mechanical findings is a minute not spent on the questions only a person can answer: is this the right approach, does it fit the architecture, will it still make sense in six months. It will not replace a reviewer, and it does not pretend to. It removes the cheap objections so that the human review starts at the interesting part.

    • Catches the mechanical findings before the review request goes out
    • Gives each finding a line number taken from the diff hunk headers
    • Runs locally, so it is safe to paste proprietary code
    Two engineers discussing a code change at a laptop
    FAQ

    Questions about the checker

    Is this an AI code reviewer or a linter?
    Neither, strictly. It is a rule-based pre-review checker. No model reads your code and nothing is generated. Thirteen pattern rules scan the added lines for the things a reviewer flags in the first thirty seconds: secrets, unsafe string-built SQL, swallowed exceptions, leftover debug output. We label it honestly because an AI code reviewer that guesses is worse than a checklist that does not.
    Does my code leave my browser?
    No. The checks run in JavaScript on this page. There is no upload, no API call and no account. The only thing recorded is an anonymous event that the tool was used, with no content from the text box.
    Where do the 200 to 400 line and test-file rules come from?
    The size threshold follows the SmartBear study of Cisco review data, which recommends reviewing no more than 200 to 400 lines at a time. The small-change rule follows Google's public engineering practices on small CLs. The missing-test rule is our convention: a diff of more than 50 added lines with no test file gets a flag, because that is a question reviewers ask anyway.
    How is the score calculated?
    It starts at 100. Each finding subtracts points by severity: 15 for high, 7 for medium, 2 for low. Each rule counts at most three times, so one noisy rule cannot zero the score. It is a convention for ordering work, not a measure of code quality. A score of 100 means no rule fired, not that the code is correct.
    What does it miss?
    Anything that needs understanding: wrong business logic, race conditions, a bad abstraction, an API that will not age well. Regex rules also give false positives, for example a test fixture that contains a fake password. Treat every finding as a question to answer, not a verdict.
    Which languages does it work with?
    The rules are text patterns, so they work on JavaScript, TypeScript, Python, Java, Go, and most C-family code. Some rules are language specific: bare except is Python, System.out.println is Java, InsecureSkipVerify is Go. Paste a unified git diff and the line numbers come from the hunk headers.
    Is it free?
    Yes, with no signup. If you want answers about the rest of your repository while you review, such as who calls this function or where a config value is read, that is what codebasechat is for.

    Review with the whole repo in view

    A diff shows what changed, not what it touches. codebasechat answers questions about your codebase in plain English, so you can check who calls the changed function before you approve.

    Try codebasechat free