Sort lines alphabetically

Why item10 usually comes before item2

Plain alphabetical sorting compares one character at a time. It reaches the 1 in item10 and the 2 in item2, sees that 1 comes before 2, and stops there. The rest of the number never gets looked at.

That is technically correct string ordering and almost never what anyone wants. It is why file managers used to list chapter1, chapter10, chapter11, chapter2 — and why every operating system eventually added natural sorting instead.

Natural ordering reads unsigned runs of digits as whole-number components rather than as characters, so item2 sorts before item10. A minus sign or decimal point separates those components: -10 is not treated as negative ten, and 1.10 is ordered like a version sequence rather than decimal 1.1. Use a numeric column in a spreadsheet or database when signed values or decimal quantities need mathematical order. Natural ordering is on by default here. Turn it off only when digit runs should be compared one character at a time, so chapter10 sorts before chapter2. Letters still use the same English-locale, case-insensitive collation.

How sort lines handles accented letters

Raw character-code sorting separates many accented letters from their base letters. That can put é far from e and Ø far from O, even when those words belong together in a practical list.

This tool uses case-insensitive English locale collation rather than character codes. Accented forms therefore stay near their base letters: Åke sorts near A, and café near cafe. The locale is fixed; it does not change with the browser language. Language-specific orders differ — Swedish, for example, places å, ä and ö after z — and need a locale-specific sorter.

Case and capitalization

Sorting is case-insensitive, so apple and Apple land next to each other rather than in two separate blocks. Raw character-code sorting puts every capitalized word before every lowercase one, which splits an alphabetical list into two alphabetical lists — technically sorted, practically useless.

What happens to blank lines

They stay, and they sort first. A blank line has nothing to compare, so it lands at the top — and the receipt says how many there were, so a list that seems one entry too long is explained rather than silently corrected. Deleting lines is a different job than ordering them; if the blanks are noise, empty them out with the text cleaner or delete them from the top of the result.

Whitespace around a line is ignored when comparing but kept in the output, so a stray space from a copy-paste does not push a line to the top, and an indented line comes back still indented.

Sorting as a step before comparing

One common reason to sort a list is that you are about to hold it up against another one — two exports of the same table, a list of users before and after a migration, the contents of two folders. Line-by-line comparison assumes the lines arrive in a comparable order, and two systems almost never agree about that.

Sort both sides here first and the ordering stops being part of the answer. What comparing the two texts shows you afterwards is membership: which entries exist on one side and not the other. That is usually the question, and unsorted input hides it behind a few hundred lines that only moved.