How Line Sorting Works: Comparisons, Case, and the Number Trap

Alphabetical order feels like something you learn in primary school and never think about again. But a line sorter implements it as one comparison applied over and over — and the fine print of that comparison explains every surprise, from why Banana beats apple to why 10 sorts before 2.

One comparison decides everything

The tool splits your text on newlines and sorts the lines with a single rule: compare two lines, and whichever sorts lower comes first. Ascending order (A→Z) and descending (Z→A) are the same comparison run in opposite directions. What makes the result predictable is that ties keep their original order — two lines with identical keys stay in the sequence they arrived in. Sort b\nA\na\nB case-insensitively and the result is A\na\nb\nB: A keeps its lead over a, and b over B, because input order is preserved whenever the comparison cannot tell two lines apart.

The case question

By default the comparison lowercases both sides first, so Banana\napple\nCherry sorts to apple, Banana, Cherry — the dictionary feel, where capitalization is decoration. Switch on case sensitivity and the comparison uses the raw characters, where uppercase sorts before lowercase (in ASCII, B is 66 and a is 97). The same list becomes Banana, Cherry, apple — every capital-initial line jumping to the top. Use the default for names, titles, and human lists; use case-sensitive mode for code, constants, and data where case is meaningful and you want strict character order.

The number trap

Text comparison is lexicographic: character by character, left to right. That is why 10\n2\n1\n100 sorts to 1\n10\n100\n2 — every string starting with 1 precedes every string starting with 2, because 1 sorts before 2 at the first character. It is correct string order and wrong numeric order, and no option changes that, because the tool's contract is lines, not values. The classic fix is zero-padding: 009, 010, 100 agree in both orders. The same trap and the same fix appear in Find & Replace, Line Sorting, and Joining Text, which covers sorting alongside its neighbouring edits.

Lines, blanks, and duplicates

Each line is one item, kept whole: a URL with slashes, a name with spaces, a CSV row all sort as single units. Blank lines are kept too, and since an empty string sorts before every character, they gather at the top. Leading whitespace is respected unless you enable Trim lines —   zebra   sorts before apple because a leading space sorts below every letter, and trimming lets it land where it belongs.

Sorted lists do real work: keyword lists ordered before pasting into a tool, bibliographies in author order, URL inventories, config entries where disorder and duplicates both need killing. A sort is also the cheapest way to check whether two lists match — identical lists sort identically, so comparing two sorted outputs is comparing two screenshots. And because a comparison is only as good as its input, lines carrying stray punctuation or ragged padding are worth normalizing first with the Find and Replace Text tool, then sorting.

Sorting has a quiet second use as well: it brings duplicate lines adjacent, which is exactly what the Remove Duplicate Lines tool then collapses — sort first, dedupe second, as laid out in The Text Cleanup Pipeline.

Try it yourself

Paste 10\n2\n1\n100 into the Line Sorter and meet the number trap in person; zero-pad the values and watch both orders agree. Sort Banana\napple\nCherry with case sensitivity off and on to watch the list reorganize itself. Then paste a list with duplicates and blank lines, sort it, and finish the cleanup in the Remove Duplicate Lines tool. To sort the words inside a sentence rather than whole lines, the Sort Words tool is the sibling built for that.