Text & wordsFree
Free line sorter. Sort text lines A-Z or Z-A, optionally case-insensitive, and remove duplicate lines.
Last updated 9 October 2026
Untick Case-insensitive above and sort the sample list. Apple comes out above apple, and if you add Zebra it lands above apple too. That is not a bug and it is not this tool being careless. It is what comparing two strings means in JavaScript: the characters are compared by their Unicode code point values, one position at a time, and the first difference decides the order.
The capital letters simply live at lower numbers than the lowercase ones. A is U+0041, Z is U+005A, a is U+0061. Every capital in the basic Latin alphabet is below every lowercase letter, so a case-sensitive sort puts the whole of A to Z before the whole of a to z. Accented letters sit higher still: é is U+00E9, above z at U+007A, which is why émile sorts after zebra rather than next to emile.
This is why Case-insensitive is ticked when the page loads. For most lists, most of the time, it is closer to what you meant.
Sort the four lines 9, 10, 100, 2 and you get 10, 100, 2, 9. Each line is text, so 1 beats 2 at the first character and nothing after that matters.
Browsers do have a fix for this. Intl.Collator with its numeric option on reads runs of digits as numbers, so file2 sorts before file10. We have not wired it in here, because switching it on quietly changes the answer for lists that are not numbered at all, and a sorter that sometimes reinterprets your text is worse than one that never does. If your lines are numbered and the order matters, pad them with leading zeros first and a plain text sort will agree with you.
The letter é can be written two ways. One is a single code point, U+00E9. The other is a plain e followed by a combining acute accent, U+0065 then U+0301. On screen they are indistinguishable in most fonts. To the comparison behind this page they are different lines of different lengths, so Unique keeps both.
Unicode calls the fix normalisation, and the relevant form here is NFC, which composes the pair back into the single character. Text that has passed through a Mac file listing, a PDF, or certain database exports is a common source of the two-code-point version, which is why a deduplicated list can still contain what looks like the same entry twice. If that is happening to you, normalise the text before sorting it.
The same trap has a duller cousin: a trailing space. cat and cat are not duplicates, and nothing on screen will tell you which line has the space. This tool does not trim lines, deliberately, because trimming is a change to your data and a sorter should not make changes you did not ask for. The Text Cleaner tool will strip trailing whitespace first if you want that.
Ticking the box lowercases both lines before comparing them, using the default Unicode case mapping. That is the right answer in most languages and the wrong answer in a few.
Turkish is the standard example. In Turkish, the lowercase of I is ı, a dotless i, and the uppercase of i is İ, an I with a dot. The default mapping does not know that and turns I into an ordinary i. Sorting is affected in the same way as searching and matching.
A second limit matters more often. Lowercasing is not collation. Real alphabetical order is language-specific: in Swedish, ä sorts after z; in German it sorts with a. Both are correct, for different readers. The Unicode Collation Algorithm exists to settle that, and browsers expose it through Intl.Collator. This page does not use it, so what you get is a consistent, predictable code point order rather than your language’s dictionary order.
Put Apple and apple into the box with Case-insensitive and Unique both ticked. Sorted A to Z you keep Apple. Tick Z-A and you keep apple instead.
The reason is the order of operations. The list is sorted, then reversed if you asked for Z-A, and only then deduplicated, keeping the first copy of each line it meets. Since the two lines compare as equal when case is ignored, the sort leaves them in the order you typed them, and the reverse flips which one is met first.
So if you are deduplicating a list where the capitalisation of the survivor matters, such as a list of names or product codes, sort A to Z. It is a small thing that is impossible to notice and easy to be bitten by.
Every one of those is a decision rather than an omission, and every one of them is reversible with a different tool before or after this one.
Intl.Collator. developer.mozilla.orgtoLocaleLowerCase. developer.mozilla.orgThe behaviours described on this page were checked against this tool’s own code on 9 October 2026. Where the page says what the tool does not do, that is a statement about this page, not about sorting in general.
Because you unticked Case-insensitive, and a case-sensitive comparison is by Unicode code point. Every capital in the basic Latin alphabet has a lower code point than every lowercase letter, so Zebra sorts above apple. Tick the box to get the order you probably meant.
The lines are compared as text, character by character, so 1 beats 9 at the first position and the rest of the line is never reached. Pad your numbers with leading zeros, so 009 and 010, and a text sort will put them in numerical order.
Almost certainly an accented character written two ways: one code point, or a plain letter plus a combining accent. They render identically and compare as different. Normalising the text to Unicode NFC first will merge them. A trailing space does the same thing and is just as invisible.
It sorts them consistently, not according to your language. Accented letters have higher code points than z, so they go to the end. Correct dictionary order differs by language, and getting it right needs a collator this page does not use.
The first one it meets after sorting. With Case-insensitive on, lines that differ only in capitalisation compare as equal, so A to Z keeps the one you typed first and Z-A keeps the one you typed last. Sort A to Z if the survivor’s capitalisation matters.
No. An empty line is a line and sorts to the top. A list that ends with a newline contains a final empty line, which is the usual reason for an unexpected blank row at the top of the output.
No. The sorting runs locally on this page. Nothing is uploaded, logged or stored, and the tool keeps working with the network disconnected once the page has loaded.
There is no limit written into the tool. The practical ceiling is your browser’s memory, and the page re-sorts as you type, so a very large paste may feel slow on a modest device.