Sort Lines by Length

About the Sort Lines by Length Tool

Each line gets measured by its character count and reordered from shortest to longest (or reversed), which is handy for things like ordering a list of tags, ranking headline options, or spotting outliers in a data dump. When two lines happen to be exactly the same length, they don't just stay in whatever order they arrived in, they get settled alphabetically instead, so the result is consistent every time you run it.

• Sort direction, shortest to longest (ascending) or longest to shortest (descending).
• Tiebreaker, lines of identical length are sorted alphabetically against each other.
• Ignore blank lines, drops empty lines from the output entirely instead of sorting them to one end (on by default).

The alphabetical tiebreaker uses locale-aware comparison, not raw character codes

Same-length lines are settled with a.localeCompare(b) rather than JavaScript's plain < or > string comparison. That distinction matters: comparing strings with < sorts purely by raw UTF-16 code unit value, which puts every uppercase letter before every lowercase letter (so "Zebra" sorts before "apple") and pushes accented letters like é far away from their base letter e, out toward the end of the alphabet near other high-code-point characters. localeCompare() instead sorts the way a dictionary or a human reader would expect, treating case differences as secondary to the letters themselves and placing accented letters near their unaccented counterparts, which produces a noticeably more natural-feeling order for same-length lines mixing cases or containing accented text.

The exact tiebreak order can vary slightly between browsers or system locales

localeCompare() is called here with no explicit locale argument, so it falls back to whatever locale the browser or operating system is currently using. For ordinary English-language text, virtually every browser and locale setting will agree on the resulting order, but for text mixing scripts, unusual punctuation, or specific accented characters, it's possible to see a marginally different tiebreak order between, say, a browser set to en-US versus one set to a different regional locale. This is expected behavior for locale-aware sorting rather than a bug, since the whole point of localeCompare is to respect regional sorting conventions rather than enforce one fixed universal order.

Truly identical lines fall back to their original order, thanks to a spec-guaranteed stable sort

If two lines are the same length and localeCompare judges them equal too — either because they're identical duplicate lines, or because they merely compare as equal under locale rules despite minor differences — the comparator returns 0 for that pair, and JavaScript's Array.prototype.sort() takes over from there. Since ECMAScript 2019, engines are required to implement a stable sort, meaning elements that compare as equal keep their original relative order rather than being shuffled arbitrarily. So two identical duplicate lines in your input will still appear in the same relative order in the sorted output that they had originally, giving this sort three effective tiers of ordering: length, then locale-aware alphabetical order, then original input position.

With "Ignore blank lines" turned off, blanks sort to one end

An empty line has a length of zero, the shortest possible value, so with the checkbox unchecked, every blank line in your input sorts to the very front in ascending order or the very back in descending order, rather than being scattered throughout the result. Multiple blank lines among each other are treated as equal-length, equal-content ties, so they end up sitting adjacent to one another in their original relative order rather than being reordered against each other.

Line length is measured in raw character count, not visual width

Every line is compared using its plain string length, counting characters rather than how wide the line actually renders on screen — a line in a narrow monospace font and a line using wide characters or a mix of scripts could occupy noticeably different visual widths while reporting the same length here. For most everyday English text this distinction rarely matters, but if you're specifically trying to gauge visual line width rather than raw character count (for a design mockup, for instance), treat this stat as a character count and not a pixel or column measurement.

Practical uses for length-based sorting

Sorting by length rather than alphabetically surfaces a different kind of pattern in a list: it's a quick way to compare a batch of headline or title options by brevity, to spot an unusually short or long entry buried in a long list of otherwise similar-length tags or keywords, or to build a staggered visual layout — like a tag cloud or a poem laid out with intentionally varying line lengths — where the order needs to actually reflect size rather than alphabetical position.