Text Sorter

Getting a list into order is trivial for a computer and tedious by hand, but the version of it most tools ship has two problems: it overwrites your list, and it only knows one kind of order. This Text Sorter writes its result into a separate box, so the arrangement you started with is still there when the ordering turns out not to be the one you wanted, and an undo button covers everything else.

Nine orderings cover the jobs people actually bring to a sorter. Alphabetical, in an alphabet you pick rather than whichever one the browser happened to default to. Natural, which reads the digits inside a string as numbers, so item2 lands before item10 the way a file manager would put it. By the number in each line, for a price list or a scoreboard. By the date in each line. By character count or by word count. A shuffle, and a plain reverse that flips the current order without sorting anything.

What gets compared is separate from what gets moved. Indentation, capitals, punctuation, accents and a leading "The" can each be excluded from the comparison without being removed from your text — so an indented outline sorts by its words rather than by its indent, and a film list files The Matrix under M while still reading "The Matrix" in the result. You can also narrow the comparison instead of loosening it: sort a CSV by column three and the entire row travels with it, or sort by a regular-expression match to order lines by a trailing number or a surname.

Two things stay put while everything else moves. A header row can be held at the top rather than alphabetized into the middle of the data, and blank lines can keep their positions so a spaced list survives with its spacing intact. Lists separated by commas, semicolons or tabs work as well as one item per line, and the result can come back separated however the next step needs it.

Reordering lines destroys any meaning that depended on their sequence, which makes a naive sort actively dangerous on a CSV, a configuration file or anything with a header. Three controls exist for that. Holding the first line or two at the top keeps a header row above the data instead of alphabetizing it into the body. Leaving blank lines where they are keeps a spaced list's structure, with the entries sorting around the gaps rather than the gaps being deleted. And comparing one column rather than the whole line means a row sorts by the field you care about while staying intact.

The column comparison is a plain separator split, not a full CSV parse: a quoted field that itself contains the separator will be split at it. For well-formed exports without embedded separators it is exact; for anything more involved, the pattern mode gives you a regular expression instead, using its first capture group as the sort key when it has one.

Both narrowing modes have to say what happens to a line that has no key — a row with fewer columns than you asked for, or a line the pattern does not match. Those lines are kept and collected at the end, never quietly interleaved into a position the comparison cannot justify, and the count is reported beneath the controls.

Comparing text proceeds character by character, and "1" comes before "9", so as far as a plain alphabetical comparison is concerned item10 precedes item9 and 100 precedes 2. This is not a bug in the comparison; it is the correct answer to a question about text being asked about numbers. Zero-padding to a fixed width is the traditional workaround, which is why files meant to sort correctly are numbered 001, 002, 003.

Natural ordering asks the right question instead. It walks the string looking for runs of digits and compares those runs as values while comparing everything around them as text, so item2, item9, item10 and item100 land in the order a person would put them. It is what a file manager uses and what a version list needs, and it is one click away here rather than an argument for renaming everything.

Ordering by the number is different again, and worth reaching for when the text around the number is noise. It finds the first number anywhere in the line — through a currency symbol, a thousands separator or a minus sign — and orders on that value alone, so a price list sorts by price no matter how each line is worded. Lines with no number in them are gathered at the end rather than treated as zero, because a missing value is not a small one.

Languages disagree about their own alphabets, and the disagreement is not a rounding error. Swedish files å, ä and ö after z, as distinct letters at the end of the alphabet. German treats the same characters as variants of a and o and files them next to their base letters. Traditional Spanish once sorted ch as a single letter between c and d. Each of those is correct in its own language and wrong in the others.

A tool that says nothing about which alphabet it is using produces a result that differs between visitors and cannot be reproduced. So the alphabet is an explicit choice here, defaulting to your browser's language and offering a list of others — plus raw character-code order, which is what the Unix sort command and most programming languages do, and which is the right answer when the output has to match something a machine produced.

Capitals interact with this. Character-code order puts every capital letter before every lowercase one, so a mixed-case list comes back in two blocks rather than one sequence — the behaviour that surprises people most. Matching case is therefore off by default; turn it on when you want the two blocks.