Text Diff Checker

Compare two texts and see exactly what was added or removed — by line or word. Free, in your browser.

Compares two texts line-by-line or word-by-word, entirely in your browser.

Free to use — premium coming soon

FREE
  • Line & word diff
  • Colour-coded changes
  • 100% private
PREMIUM
  • Remove ads
  • Side-by-side & file upload

About the Text Diff Checker

Text Diff Checker compares two blocks of text and highlights exactly what changed between them, line by line and word by word. Paste an original version on one side and a revised version on the other, and the tool marks additions, deletions, and edits in color so you do not have to hunt for them manually. It is built for the everyday moments when two versions look almost identical: a contract that came back with one quietly altered clause, a config file someone edited on the server, or a paragraph a co-writer rewrote. Instead of reading both copies twice and trusting your memory, you see the precise delta in seconds.

Reach for a diff checker whenever the cost of missing a small change is high. Developers use it to review code edits, confirm a copy-paste pasted cleanly, or compare two JSON or API responses to spot an unexpected field. Writers and editors use it to track proofreading changes when no "track changes" mode was on. Legal, finance, and operations teams use it to verify that a revised proposal, policy, or agreement only differs where it should. It is also handy for comparing two log outputs, two translations, or a draft against a published version to audit what an editor actually touched.

Under the hood, line-and-word diffing rests on the longest common subsequence (LCS) problem: finding the largest set of lines that appear in both texts, in order. Whatever is not part of that shared backbone is reported as an insertion or deletion. The classic engine here is Eugene Myers' 1986 O(ND) algorithm, which models the comparison as a shortest path through an edit graph (horizontal moves are deletions, vertical moves are insertions, diagonals are matches). The same family of algorithm powers git diff and GNU diff, so the changes you see here line up with what a reviewer would see in a pull request. You can read results as a side-by-side split view or a compact unified view.

This tool runs entirely in your browser. Both texts are compared locally with JavaScript and are never uploaded to a server, which matters when you are diffing contracts, credentials, internal configs, or anything confidential. Because it works on plain characters, results are exact and deterministic: the same two inputs always produce the same highlighted diff, with no rounding or interpretation. One thing to keep in mind is that a diff shows where text differs, not why; identical-looking changes such as a swapped straight versus curly quote, a trailing space, or a tab-versus-spaces edit are real differences and will be flagged, which is usually what you want when accuracy counts.

Frequently asked questions

What is the difference between a unified and a side-by-side diff?

Side-by-side puts the original and revised text in two parallel columns, which is easiest to read on a wide screen for quick visual comparison. Unified view interleaves both versions in a single column with added lines marked + and removed lines marked -, which is the compact format git and .patch files use and is better for narrow screens.

Does this tool do line-level or word-level differences?

Both. It first aligns the texts by line to show which lines were added or removed, and within changed lines it highlights the specific words or characters that differ, so you can see a single edited word inside an otherwise unchanged sentence.

Is my text uploaded anywhere when I compare it?

No. The comparison runs entirely in your browser using local JavaScript, so neither text leaves your device. That makes it safe for comparing contracts, configuration files, or other confidential content.

Why is the tool flagging changes I cannot see?

Diffing is exact, so invisible differences count: trailing spaces, tabs versus spaces, straight versus curly quotes, or different line endings all register as changes. These are genuine character differences, which is helpful when you need precise verification.

Will the results match what I see in git or a pull request?

Generally yes. The tool uses the same longest common subsequence approach (the Myers O(ND) algorithm family) that powers git diff and GNU diff, so additions and deletions align with what a code reviewer would see in a PR.

From our blog

How to Build CSS Gradients That Look Clean on Every Screen

By the Super Simple Digital Tools Team · Updated June 2026

Gradients are one of the few design effects in CSS that cost nothing to ship. Because the browser paints them as a generated image rather than downloading a file, a gradient background adds no extra HTTP request and stays razor-sharp at any resolution. That makes them perfect for hero sections, buttons, and overlays where a JPG or PNG would add weight and blur on high-density screens. The trade-off is syntax: the gradient functions pack direction, shape, and color stops into a single line, and that is exactly what a generator helps you assemble correctly.

Start with the workhorse, linear-gradient(). Its first value is the direction, either an angle such as 45deg or a keyword such as 'to right'. Remember that 0deg points straight up and the angle increases clockwise, so 90deg flows to the right. After the direction comes the color-stop list. At minimum you need two colors; the first sits at 0% and the last at 100% unless you say otherwise. Add a third or fourth color for richer blends, but three to four is usually the sweet spot before a gradient starts to look noisy.

Radial gradients swap the angle for a shape and size. radial-gradient(circle, ...) draws a perfect circle, while the default 'ellipse' stretches to match the box. Size keywords like closest-side and farthest-corner tell the browser where the final color lands relative to the element's edges, and the 'at' keyword repositions the center, for example 'at 30% 20%'. This is how you build a soft spotlight: a bright center color fading to a darker or transparent edge. Conic-gradient() rounds out the set by sweeping colors around a center point, which is what powers pie charts and color wheels.

Hard stops are the trick most people miss. If you give two adjacent colors the same position, for example 'red 50%, blue 50%', the blend collapses into a crisp line. Repeat that idea with repeating-linear-gradient() using fixed units like pixels and you get stripes; do it with repeating-conic-gradient() and you get pie slices or a starburst. Percentage stops will not repeat usefully because the gradient already spans the full element, so reach for px or em when you want a tiling pattern.

Finally, polish for real displays. Wide, low-contrast fades can show stair-step 'banding' on 8-bit monitors, so add an intermediate color stop or nudge the contrast to smooth it out. When a gradient fades to nothing, fade to the same color at zero alpha rather than the keyword 'transparent', which some engines interpret as transparent black and render as a gray haze. Test your final snippet against the actual background it sits on, because layered gradients stack with the first one on top.

  • Stick to three or four color stops; more than that tends to look noisy and muddy rather than smooth.
  • When fading to nothing, use rgba(r,g,b,0) instead of 'transparent' to avoid a gray banding seam.
  • Use fixed units (px or em), not percentages, with repeating-linear-gradient() so the pattern actually tiles.
  • Set two color stops to the same position to create a hard edge for stripes, checkerboards, or split backgrounds.

Read the full guide →

Tool by the Super Simple Digital Tools Team. Reviewed by our editorial team. Free to use, no signup required.

Related tools