Clean up text before you publish it
Thirteen tools for the mess in pasted text — line endings from the wrong OS, an unknown encoding, two versions you can't tell apart, inconsistent casing, and lengths that don't match where the text is going. Everything runs in your browser, so nothing you paste is uploaded.
The short answer
Text copied from a Word doc, a PDF or another codebase usually carries problems you can't see: Windows CRLF line endings where a Unix system wants LF, an unknown or legacy character encoding, or invisible whitespace. Detect line endings and encoding first, diff it against the previous version to see exactly what changed, normalise casing and slugs, then measure it — remembering that a JavaScript string's length, the Unicode character count and the UTF-8 byte count are three different numbers, and that X/Twitter counts every link as a fixed 23 characters. Each tool runs in the browser with nothing uploaded.
Fix invisible formatting problems
the stuff that breaks silentlySome text problems are completely invisible on screen and only show up when the file hits a different system — a build that rejects mixed line endings, a page that renders mojibake, a table that won't align.
Compare and merge versions
see exactly what changedEyeballing two versions of a document for differences is unreliable past a few lines. These do it precisely, down to the character.
Reshape names and structure
case, slugs, and joining linesNaming inconsistency — mismatched case conventions, unclean URLs, text scattered across lines that should be one — is one of the most common cleanup jobs there is.
Measure before you publish
count what actually countsLength limits and word counts are rarely as simple as counting characters by eye, and different platforms count the same string differently.
The problems you can't see
The most frustrating text bugs are the ones invisible on screen. Two files can look byte-for-byte identical in an editor and still be different, because the difference is in characters that don't render.
Line endings are the classic case. Windows ends a line with CRLF, Unix, Linux and macOS use a bare LF, and classic Mac used a lone CR. Paste text between systems and you get a mix, which a build step or a strict parser will reject with an error that names none of this. CRLF/LF Line Ending Converter detects the current style — including a mixed file — before converting it to one consistent ending.
Encoding is the other silent failure. If bytes were saved as Windows-1252 but get read as UTF-8, you get mojibake: a curly quote turns into three garbage characters. Character Encoding Detector sniffs a BOM to tell UTF-8, UTF-16 and UTF-32 apart, validates UTF-8 continuation bytes properly, and — when there's no BOM and the bytes aren't valid UTF-8 — falls back to a byte-frequency heuristic that guesses legacy single-byte charsets like Windows-1252 or ISO-8859-1 (Latin-1).
Seeing what actually changed
Past a few lines, comparing two versions of a document by eye stops working — the change you're looking for hides between the changes you're not. A diff tool does it mechanically.
Text Compare takes two texts and highlights added, removed and edited lines inline, with a copyable unified diff. When you need to feed the difference to something else, Git Unified Diff Patch Generator produces a genuine Git-style `.patch` with proper `@@` hunk headers, computed with the Myers diff algorithm, and lets you set the context lines and the a/b file paths.
Making names consistent
Naming cleanup is repetitive and error-prone by hand, which is exactly what makes it worth automating. String Case Converter moves text between 18 named case styles line by line — UPPERCASE, Title Case, camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE and more — so a column of inconsistent identifiers comes out uniform.
For URLs, Slug Generator turns any string into a clean, URL-safe slug, transliterating accents, stripping special characters and joining words with a dash or underscore — one per line for bulk work. When text arrived broken across lines that should be one, Text Merger joins them, removing line breaks and normalising spacing. And Text Replacer handles the surgical edits: find-and-replace with case-sensitive, whole-word, replace-first-or-all and full regex modes, including capture-group substitution and a live match count.
Counting is harder than it looks
"How long is this text" has no single answer, and publishing to a length limit with the wrong count is how a tweet gets truncated or a database field silently rejects a row.
- The string
- A single "👍" emoji
- JS .length
- 2 — UTF-16 code units (what most naive tools report)
- Codepoints
- 1 — the actual Unicode character count
- UTF-8 bytes
- 4 — how many bytes it takes to store
These three numbers diverge specifically around emoji and other multi-byte characters. String Length Calculator shows all of them at once, plus count without spaces, word count and line count, so you can see which limit you're actually up against.
- 1Assuming Twitter counts characters
It doesn't count them plainly. On X, every link counts as a fixed 23 characters via t.co no matter how long the real URL is, CJK and other wide Unicode characters count as 2, and everything else counts as 1 — all against the 280 limit. Twitter Character Counter applies those exact rules.
- 2Trusting your editor's word count for reading time
A raw character total tells you nothing about how the text reads. Word Counter breaks it into words, unique words, sentences, paragraphs and syllables, with reading time, speaking time and a top-10 word-density table updated live.
Which one do I want?
Several tools here overlap. The short version:
| Text Compare vs 3-Way Diff & Merge Viewer | Two versions — show me every line that differs between them. | Two edits of one original — merge them against their shared base. |
|---|---|---|
| Text Compare vs Git Unified Diff Patch Generator | Reading the changes on screen, inline and highlighted. | Producing a real .patch file with @@ hunk headers to apply elsewhere. |
| String Length Calculator vs Word Counter | Exact length in code units, codepoints or bytes against a hard limit. | Readability figures — words, sentences, reading time, density. |
| String Length Calculator vs Twitter Character Counter | The true technical length of a string, for a field or a byte budget. | How X will count it — links pinned at 23, wide characters as 2. |
Why this set
Line endings, encoding and stray whitespace don't show up in an editor. These surface them before the file reaches a system that rejects them.
Every tool here runs client-side. Drafts, private documents and code you paste are never uploaded to a server.
Code units, codepoints, bytes, X's 23-character links — the numbers that actually decide whether your text fits, computed properly.
Questions
What's the difference between CRLF and LF line endings?
They're two conventions for marking the end of a line. Windows uses CRLF (a carriage return followed by a line feed); Unix, Linux and macOS use a bare LF; classic Mac used a lone CR. They're invisible on screen but a strict parser or build step can reject the wrong one, and a file with a mix of styles is a common, detectable problem. The line-ending converter detects the current style and normalises it.
Why does my pasted text show garbled characters?
That's mojibake — bytes saved in one character encoding read as another. Text saved as a legacy charset like Windows-1252 or ISO-8859-1 but interpreted as UTF-8 turns accented letters and curly quotes into garbage. The encoding detector sniffs a byte-order mark to identify UTF-8, UTF-16 or UTF-32, and when there's no BOM it uses a byte-frequency heuristic to guess the legacy single-byte charset.
Why do a string's length, character count and byte count disagree?
Because they measure different things. A JavaScript string's .length counts UTF-16 code units, the Unicode character count counts codepoints, and the UTF-8 byte length counts storage bytes. For plain ASCII all three match, but they diverge around emoji and other multi-byte characters — a single 👍 is 2 code units, 1 codepoint and 4 bytes. The string length calculator shows all three so you know which limit you're up against.
Why does Twitter say my tweet is too long when it looks under 280?
Because X doesn't count characters plainly. Every link counts as a fixed 23 characters via t.co regardless of its real length, and CJK and other wide Unicode characters count as 2 each, all against the 280 limit. A long URL you thought was 60 characters counts as 23, and a line of Chinese counts double. The Twitter character counter applies those exact rules.
What's the difference between a two-way diff and a three-way merge?
A two-way diff compares text A against text B and reports where they differ. A three-way merge is for when two people each edited the same original: it compares both edits against their common base, auto-resolves the changes that don't overlap, and only flags the genuine conflicts — the same model Git uses when it merges a branch.