Tekstinsiivoustyökalu

Clean up messy text in one click

This free text cleaner fixes everything that goes wrong when you copy and paste: stray formatting, double spaces, awkward line breaks, blank lines, leftover HTML, “smart” curly quotes, em dashes and invisible Unicode. Toggle the cleanups you want and the result updates live — no upload, no sign-up, no page reload.

It's the fastest way to remove formatting from text and turn copied content from PDFs, emails, Word, Google Docs and web pages into clean, plain text you can paste anywhere.

Clean ChatGPT and AI-generated text

AI writing tools leave tell-tale fingerprints: long em dashes (—), curly smart quotes (“ ” ‘ ’), non-breaking spaces and zero-width / invisible Unicode characters that survive a normal copy-paste. The one-click Clean AI / ChatGPT text preset strips all of them at once, plus stray Markdown, so the text looks human and pastes cleanly into a CMS, code editor or email.

Turning a curly “quote” into a straight one and an em dash — into a hyphen - also stops the encoding glitches that break CSV files, JSON and plain-text systems.

Remove line breaks, \n and extra spaces

Need to remove all line breaks and join everything into one paragraph? Set the line-break mode to "Join with space". Want to replace line breaks with commas for a spreadsheet or list? Choose "Join with comma" to turn each line into a comma-separated value. The whitespace toggles also trim line ends, collapse extra spaces, convert tabs and remove blank lines in the same pass.

This covers the popular queries about removing newlines from a text file, stripping \n characters from a string, removing line spacing and handling remove line breaks in Word or Excel — all done without macros, plugins or Find & Replace juggling.

Strip HTML, Markdown, emojis and Unicode

Paste a chunk of web content and turn on Strip HTML to drop every <tag> and decode entities like  . Strip Markdown removes headings, **bold**, _italic_, links and code fences. Remove emojis clears 😀 and flag / skin-tone sequences, while Remove non-ASCII — a true Unicode text cleaner — reduces text to plain 7-bit ASCII.

Optional toggles also strip punctuation, symbols or numbers for the times you need only the words.

Presets, live counts and export

Five one-click presets — Clean AI text, Remove all formatting, Single line, Tidy whitespace and Plain ASCII — set the right toggles instantly, and you can fine-tune from there. Live counters show characters, words and lines for both the input and the cleaned output, plus exactly how many characters were removed. When it's ready, Copy the result or Download it as a .txt file.

How this compares to TextSoap, Text Mechanic and TinyWow

TextSoap (by Unmarked Software, $40) handles most of the same cleaning but is macOS-only, costs money, and has no browser version or AI-text preset — so if you're on Windows, Linux or a phone, it's not an option. Text Mechanic (textmechanic.com) is free and well-known but spreads its features across separate pages: one page for removing blank lines, another for removing line breaks, a third for stripping HTML. There's no combined workspace and no AI cleanup preset.

TinyWow includes text tools, but documents you paste are sent to TinyWow's servers for processing. That's fine for non-sensitive content, but it means your text leaves your device. The same applies to many other "online text cleaners" that quietly perform their work server-side. UtiloKit's text cleaner does all the work locally using JavaScript in your browser tab — nothing is sent anywhere, the tool works offline after first load, and there are no usage limits or watermarks.

Private, instant and offline

There's nothing to install and nothing to sign up for. Every cleanup — collapsing spaces, stripping HTML, straightening quotes, removing invisible Unicode — happens locally in your browser, so your text never leaves your device. Because it doesn't depend on a server, this text cleaner keeps working offline once the page has loaded. Bookmark it and tidy up text any time.

The hidden-characters problem: smart quotes, zero-width spaces and byte-order marks

When you copy text from a word processor or website, a class of characters travels along invisibly and causes breakage that is almost impossible to diagnose by eye. Smart quotes — the typographic left and right double quotes (U+201C “ and U+201D ”) and left and right single quotes (U+2018 ‘ and U+2019 ’) — look fine in print but are completely different code points from the straight ASCII quote (U+0022) and straight ASCII apostrophe (U+0027) that JSON, CSV, SQL, shell scripts and most programming languages expect. A JSON value like {"key": “value”} is a syntax error; a SQL WHERE name = ‘Alice’ will silently return zero rows.

Zero-width spaces (U+200B) are single characters that render as nothing at all — no glyph, no width — yet they land in the middle of words when you copy from websites, PDFs or AI tools. A search for the word "résumé" will miss an identical-looking word that contains a zero-width space after "é". The zero-width non-joiner (U+200C) and soft hyphen (U+00AD) cause the same invisible-mismatch problems, while the byte-order mark (U+FEFF, BOM) — prepended to files saved by Windows Notepad in UTF-8 mode — breaks the first field of every CSV and causes "\xEF\xBB\xBF unexpected token" errors in parsers that do not explicitly strip it. The only reliable fix is to run text through a cleaner that knows about all of these code points and deletes them in one pass.

Detection is the first hurdle: none of these characters are visible in standard text editors or word processors. You need either a hex editor or a tool that explicitly targets them. The Remove invisible Unicode toggle here deletes zero-width spaces, zero-width non-joiners, soft hyphens and the BOM in a single step, and the Straighten quotes toggle maps all four curly-quote variants to their plain ASCII equivalents, so copied text becomes safe to paste into code, config files and databases.

Unicode normalization: why two identical-looking strings are not equal

Unicode allows the same visible character to be encoded in more than one byte sequence. The letter ü, for example, can be stored as a single composed code point U+00FC (NFC form — precomposed) or as the plain letter u (U+0075) followed by a combining diaeresis (U+0308) that attaches the dots (NFD form — decomposed). Both render identically, but a byte-for-byte string comparison returns false, a regular expression match fails, and a dictionary lookup misses the key. This causes silent data corruption in databases, filesystem errors and broken search indexes.

The problem is particularly acute in a few real-world scenarios. URL slugs derived from headings can collide or 404 depending on which normalization form the server and the browser each chose. macOS stores filenames in NFD; Windows and most Linux filesystems use NFC. A file named café.txt copied between platforms can produce two files with the same visible name that are actually different paths. NFKC and NFKD go further: they also expand compatibility characters, converting ligatures like fi (U+FB01) to the two-letter sequence fi, and collapsing stylistic variants like the Roman numeral Ⅳ (U+2163) to the plain letters IV — essential when the text needs to be searchable or indexed. Most modern databases and search engines normalize internally, but data flowing in from external sources — web scraping, file imports, API responses — should be normalized to a consistent form before storage.

The practical fix for most text-processing work is to normalize everything to NFC before comparison or storage, and to use NFKC when you need full compatibility decomposition for search. In JavaScript, str.normalize('NFC') does the job. The text cleaner applies this normalization as part of its Unicode cleanup, so strings that looked equal but compared unequal in your code come out with consistent encoding.

Mojibake: what text encoding errors look like and how to fix them

Mojibake (文字化け — Japanese for "character transformation") is the garbled text that appears when bytes written in one encoding are read back in a different one. The most common case on the web is UTF-8 text misread as Windows-1252 (also called cp1252 or "ANSI"), which was the default encoding in older versions of Windows and Internet Explorer. The right single quote ’ is stored in UTF-8 as the two-byte sequence 0xE2 0x80 0x99; when those bytes are decoded as Windows-1252 they produce the three-character string ’. Similarly, the lowercase e with acute (é, U+00E9) encodes to 0xC3 0xA9 in UTF-8, which Windows-1252 reads as the two-character string é. Once you learn these patterns you can spot mojibake instantly.

The encoding declaration pipeline has three layers, and a mismatch at any one of them causes the problem. The HTML meta charset tag (<meta charset="utf-8">) tells the browser how to decode the page. The HTTP Content-Type header (Content-Type: text/html; charset=utf-8) takes precedence over the meta tag when both are present. The database collation — for example utf8mb4_unicode_ci in MySQL — determines how the database stores and compares strings. A mismatch between any two of these layers is enough to corrupt characters, and the corruption can be cumulative: text that has already been mis-encoded once can be mis-encoded again, producing double-mojibake like ‘ for a left single quote.

Windows-1252 is almost identical to ISO-8859-1 (Latin-1) but assigns different characters to the byte range 0x80–0x9F, which ISO-8859-1 leaves as control characters. The printable characters in that range include the euro sign € (0x80), single and double low-9 quotation marks ‚ and „ (0x82, 0x84), the horizontal ellipsis … (0x85) and em dash and en dash — and – (0x97, 0x96). When those Windows-1252 bytes are decoded as Latin-1, these characters disappear or become control codes. Diagnosing mojibake is straightforward: if you see ’ or é, the bytes were UTF-8 but were decoded as Windows-1252. If you see boxes or question marks, the bytes contained a code point the chosen encoding does not define at all. The fix is always to identify the true source encoding and re-decode the raw bytes correctly before any further processing.

Whitespace taxonomy: the spaces that are not spaces

Not all whitespace is the regular space character (U+0020). Web content, word-processor output and internationalized text regularly contain space characters that look identical to a normal space but behave differently in layout, search and string processing. The most common is the non-breaking space (U+00A0,   in HTML), which prevents a line break between the words on either side of it. In a browser that renders correctly, but in a text field or database, a search for "New York" will miss "New York" with a non-breaking space — they are different bytes. The non-breaking space is extremely common in text copied from web pages because browsers insert it automatically to preserve whitespace runs.

Beyond the common cases, Unicode defines an entire set of width-specific space characters used in professional typography. The thin space (U+2009) is used around mathematical operators and in some number formatting standards (e.g., 1 000 000 instead of 1,000,000). The hair space (U+200A) is even narrower and appears in typeset books around punctuation. The figure space (U+2007) is exactly as wide as a digit, used to align columns of numbers. The em space (U+2003) matches the current font's em. The ideographic space (U+3000) is a full-width space used in CJK (Chinese, Japanese and Korean) text where every character occupies the same square block; it is visually indistinguishable from a full-width ideograph to a non-reader but is double the width of a Latin space.

Line endings are the other dimension of whitespace ambiguity. Windows uses the two-byte sequence carriage-return + line-feed (CRLF, U+000D U+000A). Unix and modern macOS use line-feed alone (LF, U+000A). Classic Mac OS (pre-OS X) used carriage-return alone (CR, U+000D). A file saved on Windows and opened in a Unix tool often shows literal ^M characters at the end of every line; a file saved on classic Mac OS shows the entire content as a single line in most modern editors. The correct approach before any text processing is to normalize all line endings to one consistent form — almost always LF — and to convert all exotic space characters to regular spaces or remove them, depending on whether the surrounding text is destined for display or for a data field.