Ask for sorted lines and there are at least five different correct answers. Choosing the wrong one produces output that looks sorted and is not.
item10 comes before item9. Default sorting is lexicographic — it compares character by character, left to right. At position five, the character 1 is lower than 9, so item10 wins and the digits after it are never examined:
| Lexicographic | Natural |
|---|---|
| item1 | item1 |
| item10 | item2 |
| item11 | item9 |
| item2 | item10 |
| item9 | item11 |
Natural sort fixes this by detecting runs of digits and comparing them as numbers. It is what file managers use, and it is what you want for anything containing version numbers, chapter labels or filenames.
Zebra comes before apple. In ASCII and Unicode code-point order, every uppercase letter sits below every lowercase one — A is 65, Z is 90, a is 97. So a case-sensitive sort produces all the capitals first:
Apple, Banana, Zebra, apple, banana
rather than the case-insensitive result most people expect:
apple, Apple, Banana, banana, Zebra
Alphabetical order is not a universal fact. It depends on the language:
Locale-aware comparison handles these; naive code-point comparison does not, and will place accented words in an order that looks arbitrary to a native reader.
Lines that are purely numbers must be compared as numbers, or you get 1, 10, 100, 2, 20, 3. Watch for negative signs, thousands separators, and decimal commas versus points — 1,5 is one and a half in much of Europe and fifteen hundred elsewhere, and no sorter can tell which you meant without being told.
Sorting discards structure. If your lines are CSV rows with a header, sorting moves the header into the middle of the data — remove it first. If a record spans multiple lines, line sorting destroys it. Blank lines cluster at the top in most orders and are easy to miss.
Stability matters too: a stable sort preserves the original relative order of lines that compare equal, which is what makes multi-pass sorting work — sort by the secondary key first, then the primary. An unstable sort makes that technique unreliable. And for very large inputs, browser-based sorting is limited by memory; command-line tools handle files that will not fit in RAM by sorting in chunks.
Case-insensitive natural sort matches human expectation most often. Use strict lexicographic only when you specifically need byte order, such as when matching another system output.
Usually invisible characters — trailing spaces, tabs, or Windows carriage returns at line ends. Trimming before comparison resolves nearly all of these.
Not with plain line sorting. You need a delimiter and a field index, which is what a spreadsheet or a command-line tool with field support gives you.
No. Sorting happens in your browser and nothing you paste is transmitted or stored.
Every tool comes with a written guide, and every category is one click away.