Sort Lines by Length
Order a list from shortest line to longest, or the reverse.
Apply Unicode normalisation so identical-looking text really matches.
All four Unicode normalisation forms are produced below. NFC is what the web and most databases expect; NFKC and NFKD fold compatibility variants and genuinely lose information.
Normalize Text applies Unicode normalisation so that strings which look identical actually compare as equal. All four forms are produced side by side — NFC for storage and comparison, NFD before stripping accents, NFKC and NFKD to fold compatibility variants — with the code point counts that show what changed.
Two strings can look identical on screen and still not be equal, because Unicode often offers more than one way to write the same thing. The letter é can be a single character, or an e followed by a separate combining accent. They render the same and compare as different, which is why a search fails on text that is visibly there.
Normalisation resolves that by rewriting text into one canonical form. NFC composes characters together and is what you want for storage and comparison — it is the form the web has standardised on. NFD decomposes them, which is what macOS filesystems use and what you need before stripping accents. NFKC and NFKD go further and fold compatibility variants, so a full-width A becomes a plain A and a fi ligature becomes two letters. All four are here, with a comparison showing exactly what changed.
Rather than converting blind, you see what each form does to your text before choosing one.
The difference between composed and decomposed is invisible on screen but obvious in the counts.
The characters that changed are marked, so you can see exactly where the two encodings diverged.
The page says plainly that NFC is right for the web and NFKC loses information, so the choice is informed.
Accented Latin, Korean Hangul, full-width CJK forms and ligatures are all normalised correctly.
A string that is failing a comparison, or data from a system with different conventions.
NFC for storage and comparison, NFD before removing accents, NFKC or NFKD to fold compatibility variants.
All four results are shown with their code point counts, so the difference between them is visible.
Copy the form you need, ready to store or compare.
NFC for nearly everything — it is what the W3C recommends for the web and what most databases expect. Use NFD only when you need decomposed characters, typically before stripping accents or when working with macOS filenames.
NFC only combines characters that are canonically equivalent, so nothing visible changes. NFKC also folds compatibility variants, turning full-width letters, ligatures and superscripts into their plain equivalents — useful for search, but it genuinely loses information.
Usually because the search term and the document use different normalisation forms for the same accented character. Normalising both to NFC makes them equal.
NFC and NFD are reversible with respect to each other. NFKC and NFKD are not — once a full-width character has been folded to a plain one, the original form is gone.
What people who use the Normalize Text think of it. Reviews come from visitors and are posted as written.
No ratings yet
Yours would be the first.
0 reviews
Newest first
No reviews yet
Be the first to rate the Normalize Text. It takes half a minute and no account.
Write the first reviewOrder a list from shortest line to longest, or the reverse.
Spell out text using Alfa, Bravo, Charlie and the rest.
Read any text aloud using the voices on your device.
Count consonants in any text and see which letters dominate.
Pull every link out of HTML with its anchor text.
Generate placeholder paragraphs, sentences or words for your mockups.
Cycle text through every case format from one box.
Generate realistic sample records: names, emails, addresses, dates.