Sort Lines Alphabetically, Numerically, or by Length

Five sort modes share a common pipeline: split the input into lines, decorate each line with the value used for comparison (collation key, parsed number, code-point length, or a random uint32), sort the decorated pairs, then re-emit the original lines in the new order. The decorate-sort-undecorate pattern is the standard trick for keeping the comparator at O(n log n) calls when the key derivation is non-trivial.

1. Split. The input is broken on the regular expression /\r?\n/, so LF (Unix/macOS), CRLF (Windows), and mixed inputs are all handled. A single trailing newline is detected and stripped before splitting, then re-appended at the end so a file like "a\nb\n" stays two lines, not three.
2. Decorate. For alphabetical and natural mode each line is paired with an Intl.Collator key in the chosen locale — natural mode sets numeric: true so embedded digit runs sort as numbers. For numeric mode each line is parsed by a regex that accepts optional sign, integer and decimal parts, and scientific notation, then handed to parseFloat. For lengthmode the line's code-point count is computed by iterating the string with a for-of loop, so multi-byte characters count as one symbol — not the two UTF-16 code units String.length would report.
3. Sort. JavaScript's Array.prototype.sort has been stable since ECMA-262 §23.1.3.31 was finalised in 2019. Stability matters when sorting by length or by a case-folded key — two lines that share a key keep their input order, so a sort never silently scrambles your data. Descending direction flips the comparator's sign rather than reversing the array, which preserves the stable-order guarantee within tie-groups.
4. Random. Random mode skips the comparator entirely and runs a Fisher-Yates (Knuth) shuffle: walk the array right-to-left, swap each element with a uniformly-random earlier element. Indices are drawn from crypto.getRandomValues with rejection sampling, so the result is bias-free. Click Re-shuffle to draw a fresh permutation without re-typing.
5. Cross-check. Every result runs two independent verifications. The first walks the output and confirms each adjacent pair is in the correct order under the chosen comparator — skipped for random mode. The second compares the input and output as multisets to confirm no line was added, lost, or duplicated. Both pass on every sort the algorithm performs correctly; if either fails, the badge on the calculator card flips red and the bug is yours to report.

A deliberate non-feature: Unicode normalisation is not applied. If two lines look identical but use different code-point sequences (precomposed é vs decomposed e + ◌́), they may sort to neighbouring positions but they remain distinct lines. That mirrors what every text editor shows you and avoids silently collapsing intentionally-different encodings — usually the wrong default for source code and data work.

• ECMA-262 — Array.prototype.sort (stable since 2019)
• ECMA-402 — Intl.Collator (locale-aware string comparison)
• Unicode TR-10 — Unicode Collation Algorithm
• WHATWG Encoding Standard — line terminators (LF, CR, CRLF)
• W3C Web Crypto — crypto.getRandomValues
• MDN — Intl.Collator reference

The sort modes and comparators on this page were last cross-checked on 2026-05-11. The page is reviewed whenever a TC39 proposal changes the relevant Array or Intl.Collator algorithms.