Sort Lines of Text Alphabetically or Numerically

Why the obvious sort gets it wrong

Every programming language ships a sort that compares strings by their underlying character codes. In JavaScript that means ['Zebra', 'apple'].sort() returns ['Zebra', 'apple'], because capital Z is code point 90 and lowercase a is 97. Every capital letter sorts before every lowercase one. Nobody alphabetising a list of names wants that.

Accents are worse. In code point order é lands after z, so a list of French or Spanish words comes back with a random-looking tail. And if an accent is stored as a plain letter plus a combining mark rather than a single character, the same word can sort in two different places depending on where it was typed.

Your language settings uses the browser's collation, which knows that a and A belong together, that é sits next to e, and how your locale expects the alphabet to run. Code point gives you the raw comparison, which is what you want when you are matching what a program, a database index or a sorted file will do.

Collation depends on who is looking

This is the honest caveat. Locale-aware sorting is genuinely locale-aware: in Swedish, å, ä and ö come after z, while German treats them as variants of a and o and files them accordingly. Estonian puts z between s and t. The tool uses whatever language your browser is set to, so the same list sorted by two different people can come out in two different orders. If the order has to be identical everywhere, use code point.

Natural order and where it stops being obvious

Plain alphabetical sorting reads digits as characters, so file10 comes before file2 — 1 is less than 2 and the comparison ends there. Natural order reads runs of digits as numbers instead, which is what a human expects from a list of filenames, chapters or issue numbers.

It is not a universal fix. Version numbers break it: under natural rules 1.10 is compared as one followed by ten, which is correct for versions and wrong for decimals, where 1.10 equals 1.1. Dates written as 3/4/2025 sort by the day or the month depending on which comes first in the string, and never by the actual date. Leading zeros mostly work, but 007 and 7 compare equal, so their relative order comes down to which one you typed first.

That last point holds generally: JavaScript's sort has been required to be stable since ES2019, so items the comparison calls equal keep their original relative order. Sorting a list twice by two different keys therefore works the way you would hope.

The other three orders

Line length sorts by character count, with ties broken alphabetically. Characters, not visual width — an emoji or a Chinese character counts as one or two units depending on how it is encoded, so this is a rough measure for anything but plain Latin text.

The number in the line pulls out the first number it finds anywhere in each line and sorts on that value. This handles Chapter 9 before Chapter 10, and it handles 12 Acacia Avenue. It also means Chapter 2 of 10 sorts on the 2, which is usually right, and Route 66 revisited in 1998 sorts on the 66, which may not be. Lines with no number at all are parked at the end in their original order rather than pretending to be zero.

Random shuffle uses a Fisher-Yates shuffle driven by Math.random. That is fine for picking a running order or mixing up flashcards. It is not cryptographically random, so do not use it to draw a prize or anything where someone has a reason to game it.

What it cannot do

It sorts lines, and only lines. A CSV whose fields contain quoted newlines will be split in the wrong places, and sorting by the third column is not something a line-based tool can offer — that needs a spreadsheet. There is no secondary sort key, no grouping and no sorting of indented outlines, where moving a parent line away from its children destroys the structure. Everything runs on your tab's main thread, so a list in the hundreds of thousands of lines sorts instantly and one in the millions will make the page hang while it works.

Last updated September 19, 2026