Text Tools: Everyday Cleanup, Counting, and Formatting Utilities

Text tools handle the small, constant jobs that come up whenever you move writing between applications. This category collects utilities for changing case, removing duplicate lines, stripping HTML, counting words, fixing whitespace, finding and replacing, and detecting the invisible characters that cause text to behave strangely for no visible reason.

These are the tools you reach for when something is wrong and you cannot see why. Text that will not match in a search. A word count that disagrees between two programs. Spacing that changes when the page renders. A spreadsheet import that fails on a file that looks perfectly fine. In most cases the cause is a character that occupies space in the data and nothing on screen.

The tools divide roughly into three jobs. Some inspect, reporting what is present without changing anything, which is where you should usually start. Some clean, removing characters or formatting that should not be there. Some transform, changing case, extracting values, or substituting text. Reaching for a cleaning tool before you have inspected is the most common way to apply the wrong fix and still not understand the original problem.

Every tool here runs entirely in your browser. Nothing you paste is uploaded, logged, or stored, which matters because these utilities routinely handle unpublished drafts, client material, and internal documents.

Invisible Characters: The Cause of Most Mysterious Text Problems

The invisible character detector, invisible character remover, zero-width space remover, and character remover address a category of problem that is genuinely invisible and therefore extremely frustrating to diagnose.

Unicode contains many characters that occupy no visual space or are indistinguishable from ordinary ones. They arrive through copy-paste from web pages, PDFs, word processors, and AI output, and once present they travel silently through every subsequent operation.

Zero-width characters render as absolutely nothing. The zero-width space (U+200B), zero-width non-joiner (U+200C), zero-width joiner (U+200D), and word joiner (U+2060) have no width and no mark, yet they count as characters, break word boundaries, and prevent string matches. A zero-width space inside a word means a search for that word fails while the text looks identical on screen.

Non-breaking spaces (U+00A0) look exactly like ordinary spaces but prevent line wrapping and do not match a regular space in comparisons. This is why a paragraph occasionally refuses to wrap correctly, and why find-and-replace skips instances that are visibly right there.

Byte order marks (U+FEFF) sometimes appear at the very start of copied text and cause parse errors in JSON, CSV, and configuration files. The error points at position zero while the file looks flawless in an editor, which makes it a memorably annoying bug.

Directional marks (U+200E, U+200F) control bidirectional text ordering and can make characters appear in an unexpected order when they turn up unintentionally.

The invisible text copy-paste tool works in the other direction, generating invisible characters deliberately, which people use for blank messages and usernames on platforms that require non-empty input.

There is also a security dimension worth knowing about. Because certain Unicode characters are visually identical to Latin letters while being entirely different code points, they can be used to construct strings that look legitimate and are not. A Cyrillic letter that renders identically to a Latin one makes a convincing lookalike domain or filename. Invisible characters can likewise be used to slip content past naive keyword filters. Detecting what is actually present, rather than trusting what renders, is the defence in both cases.

Case Conversion

The case converter switches text between uppercase, lowercase, title case, sentence case, and other variants. Straightforward in principle, with two complications worth knowing.

Title case is not a single standard. Different style guides disagree about which words to capitalize. AP style capitalizes words of four letters or more; Chicago capitalizes principal words and lowercases articles, prepositions, and coordinating conjunctions regardless of length. Both capitalize the first and last word whatever they are. This is why automated title case sometimes produces results that look wrong: it is following a different convention from the one you have in mind.

Case conversion is language-dependent. Turkish has both dotted and dotless i, and naive uppercasing of Turkish text produces the wrong letter, which is a well-known source of bugs in software that assumes English casing rules apply universally. German sharp s traditionally uppercases to a two-letter sequence. Greek final sigma changes form depending on position.

Whitespace and Line Handling

The whitespace remover, space remover, paragraph space remover, line break remover, and Excel space remover normalize spacing.

Whitespace problems are common because different systems represent line endings differently. Windows uses carriage return plus line feed; Unix, Linux, and modern macOS use line feed alone. Text moved between them can show as one long line, display stray characters, or produce doubled spacing. This is also why a file edited on two operating systems can appear entirely rewritten in a version control diff when nothing meaningful changed.

Trailing whitespace deserves specific mention because it is invisible and consequential. In code it produces noisy diffs where lines appear changed although nothing meaningful differs, which makes review harder and pollutes blame history. In data files it causes lookups to fail, since a trailing space makes an otherwise matching value distinct.

The Excel space remover addresses a specific recurring problem. Spreadsheet data frequently carries leading or trailing spaces from imports and manual entry, which break VLOOKUP and other exact-match functions in ways that are hard to spot because the cells look correct.

Duplicates, Sorting, and Extraction

The duplicate line remover deduplicates lists, which sounds simple until you consider what counts as a duplicate. Lines differing only in case, or in leading or trailing whitespace, or in whether they contain a non-breaking space rather than a regular one, are visually identical and textually distinct. This is why deduplication sometimes leaves entries that clearly look the same, and why cleaning whitespace before deduplicating gives better results.

The number extractor pulls numeric values out of surrounding text, useful for processing reports, logs, and pasted content where the figures matter and the prose does not.

The word descrambler finds words that can be formed from a set of letters, which serves word games and puzzles.

Finding, Replacing, and Counting

The find and replace toolperforms bulk substitution across text, with the advantage over an editor's built-in version of operating on pasted content without touching a file.

The reason find and replace appears to fail is nearly always an invisible character. If you are searching for a phrase that is visibly present and getting no match, run the invisible character detector first. A non-breaking space where you typed a regular space, or a zero-width character between two letters, makes the strings genuinely different.

The word counter counts words, characters, sentences, and paragraphs. Counts vary between applications more than people expect, because different programs make different decisions about hyphenated words, numbers, contractions, and whether headers, footnotes, and captions are included. Invisible characters widen the gap further by breaking word boundaries. Where a limit is enforced, check what the enforcing system counts rather than assuming.

Formatting and Markup Removal

The HTML stripper removes tags and returns plain text, useful for extracting content from scraped pages, email source, or CMS exports.

The formatting remover, format remover, and clean paste toolstrip rich text formatting so pasted content adopts the destination's styling rather than importing its source styling. This is the problem behind text that pastes into a document carrying the wrong font, size, and color, and it is the single most common formatting complaint in word processing.

The em dash remover converts em dashes to hyphens or other punctuation. Em dashes are typographically correct in published prose and actively harmful in code, CSV, and any ASCII-expecting system. They have also become the most recognizable stylistic marker of AI-generated text, since models use them at well above natural human frequency. The em dash copy-paste tool serves the opposite need, when you want a proper em dash and your keyboard has no direct key for it.

AI Text Cleanup

The ChatGPT text cleaner, text cleaner, and ChatGPT line spacing tool combine several operations for the specific case of preparing AI output for publication.

AI output is rarely plain text. It typically carries smart quotes, em dashes, non-breaking spaces, occasional zero-width characters, and sometimes literal Markdown syntax that the destination editor will not interpret. Running one combined cleanup is faster than applying five separate tools.

For model-specific cleaners and a fuller treatment of AI text artifacts, see the AI cleanup tools category.

Understanding Character Encoding

Most text problems trace back to encoding, and a working understanding of it turns a class of baffling bugs into obvious ones.

Characters versus bytes. A character is what a reader sees. A byte is what the computer stores. In ASCII these mapped one to one, which is why the distinction went unnoticed for decades. Unicode assigns a number, called a code point, to every character across every writing system, and an encoding determines how those numbers become bytes.

UTF-8 is the encoding to use. It represents ASCII characters in a single byte, keeping English text compact and backward compatible, while using two to four bytes for everything else. It is now the overwhelming majority of web content. Problems arise almost entirely when something assumes a different encoding.

Mojibake is what encoding mismatch looks like. When UTF-8 bytes are interpreted as Latin-1 or Windows-1252, each byte of a multi-byte character is rendered separately, producing the characteristic garbled sequences where a single curly apostrophe becomes several strange symbols. The data is usually intact; only the interpretation is wrong, which means it is often recoverable if you identify the mismatch.

Replacement characters mean information was lost. A black diamond with a question mark, or a plain question mark where a letter should be, indicates the system could not represent the character at all and substituted a placeholder. Unlike mojibake, this is usually unrecoverable, because the original value is gone rather than misread.

Normalization forms matter for comparison. Unicode often allows the same visible character to be encoded more than one way. An accented e can be a single precomposed code point or a plain e followed by a combining accent. Both look identical and neither is wrong, but they are different byte sequences, so comparisons fail and uniqueness constraints treat them as distinct. Normalizing to NFC before storing or comparing eliminates the problem.

How Text Length Is Measured

String length is far less obvious than it appears, and the disagreement between systems causes real bugs.

Three different counts exist for the same text. Bytes, which is what storage and transmission care about. Code points, which is roughly what Unicode considers a character. Grapheme clusters, which is what a reader perceives as a single character.

A plain letter is one of each. An emoji may be one grapheme cluster, two UTF-16 code units in JavaScript, and four bytes in UTF-8. Emoji built from zero-width joiner sequences, such as family or profession emoji, can span a dozen code points while a reader sees one symbol. Flag emoji are pairs of regional indicator symbols.

This explains several persistent problems. A database column declared to hold 255 characters does not reliably hold 255 arbitrary Unicode characters, because the limit may be in bytes. Browser validation using a string length property can disagree with server-side validation counting bytes, letting input pass one and fail the other. And truncating text at a fixed length can split a grapheme cluster, producing a broken character or an emoji that renders as unrelated components.

The practical rule: when a limit matters, find out what unit is being counted rather than assuming it matches what you see.

A Diagnostic Guide

Matching symptoms to causes, since the same few problems account for most text trouble.

Search finds nothing although the text is visibly there. An invisible character inside the string, or a non-breaking space where you typed a regular one.

Text pastes with the wrong font and color. Rich text formatting travelled with it. Use a clean paste tool or paste as plain text.

A line refuses to wrap and breaks the layout. A non-breaking space is preventing the wrap. It is invisible and identical to a normal space.

Character count exceeds a limit although visible text is shorter. Invisible characters counting toward the total, which matters for meta descriptions and social posts.

A CSV or JSON file fails to parse at position zero. A byte order mark at the start.

VLOOKUP fails on values that match. Leading or trailing whitespace in one of them.

Deduplication leaves obvious duplicates. Differences in case, whitespace, or space type. Normalize before deduplicating.

A file shows as entirely changed in a diff. Line ending conversion between Windows and Unix conventions.

Accented text will not match despite looking identical. Unicode normalization: the same character encoded two different ways. Normalize both sides to NFC before comparing them, and the mismatch disappears. This affects non-English text and copied web content most often.

Where Text Problems Come From

Knowing the usual sources helps you anticipate what cleaning a given piece of text will need.

PDFs are the worst offender. A PDF stores glyph positions rather than flowing text, so copying reconstructs a plausible reading order that is frequently wrong. Multi-column layouts interleave. Ligatures such as fi and fl may copy as single characters that break search. Hyphenation inserted for line breaks becomes literal hyphens mid-word. Headers and footers interrupt the body. Text copied from a PDF almost always needs work.

Word processors carry formatting and autocorrect artifacts. Autocorrect converts straight quotes to curly ones, hyphens to dashes, and applies capitalization rules, all of which are correct in the document and often wrong in the destination. Tracked changes and comments can surface unexpectedly when content is copied.

Web pages carry markup and styling. Copying from a browser brings HTML structure, inline styles, and often non-breaking spaces used for layout. Content management systems then re-encode this, sometimes double-encoding entities so an ampersand appears as its escaped form rather than the symbol.

Spreadsheets coerce values aggressively. Excel converts anything resembling a date into one, strips leading zeros from identifiers and postcodes, and truncates long numbers into scientific notation. These changes happen on open, before you have done anything, which is why importing through the data import path rather than double-clicking a CSV matters.

AI output carries its own signature. Smart quotes, em dashes at high density, occasional zero-width characters, and literal Markdown that the destination will not render.

Messaging and email clients reformat silently. Line breaks are inserted at fixed widths, URLs are linkified, and quoting adds prefix characters that survive copying.

Working With Large Volumes

These tools handle individual passages well. When you are processing a lot of text, a few practices make the work reliable rather than repetitive.

Fix problems at the source when you can. If every export from a system carries the same artifact, changing the export settings once is better than cleaning every file. Many systems offer a plain text or UTF-8 export option that eliminates the problem entirely.

Establish the pattern on a sample first. Run the detector on a representative piece, work out exactly which operations are needed and in what order, then apply that sequence. Discovering on file forty that an earlier step was wrong is expensive.

Keep the original. Cleanup is lossy by design, and you occasionally discover that something you removed mattered. Working on a copy costs nothing and preserves the ability to start again.

Verify in the destination, not the tool. Text that looks correct after cleaning can still behave unexpectedly in the target application. The destination is the only ground truth, and checking one item there before processing hundreds saves rework.

Normalize before comparing anything. Whether you are deduplicating, matching records, or diffing versions, running normalization first makes the comparison meaningful. Most apparent tool failures in comparison tasks are normalization that did not happen.

Related Tool Categories

For AI-specific cleanup across models, see the AI cleanup tools. For Base64, URL encoding, and binary conversion, see the encoding tools. For grammar, readability, and tone, see the writing tools. For regex testing, diffing, and formatters, see the developer tools. The full tool directory is searchable.