Sorting a list alphabetically sounds like the most solved problem in computing, and then you paste one in and get back Banana, Cherry, apple. Or item1, item10, item2. Or every accented surname dumped in a clump after Z. That is not a bug in your list - it is what almost every online sorter does, because the code behind it is one line long and that line is not sorting alphabetically at all. Here is what it does instead, and how to get the order you expected with Sort Lines.
Why your sorted list came back wrong
The one-line version of a sort, in the language most of these tools are written in, is items.sort(). With no instructions it compares two strings by the numeric code of their characters, and every capital ASCII letter has a lower number than every lowercase one - A is 65, a is 97. So the result is not A-to-Z at all: it is all the capitals first, in order, then all the lowercase words, in order.
Feed it banana, Apple, Cherry and you get Apple, Cherry, banana. That looks almost right, which is what makes it easy to ship - until one name is typed in lowercase and the list splits into two alphabets.
It gets worse past ASCII. An accented character has a far higher code number than any plain letter, so a code-order sort files Arger - spelled with an A-umlaut - after Zug rather than next to Apfel. A list of European names comes back scrambled, and a non-Latin script is ordered by the internal numbering of the character set, which matches nothing a reader would recognise.
Alphabetical order is a property of a language, not of the alphabet
You cannot patch this by lowercasing everything first, because alphabetical order is a per-language convention and the languages disagree.
- In English and German, a word starting with an A-umlaut files with A: Angel sorts between Andrew and Apple.
- In Swedish, that same letter is a separate letter of the alphabet and comes after Z, so the identical list sorts Bok, Zebra, Angel.
- In Spanish, n-with-tilde is its own letter following n, so a word starting with it sorts after every plain-n word but before one starting with o.
Browsers already ship all of this: the Unicode collation data behind Intl.Collator is the same table your operating system uses to sort a folder of files, and it is what Sort Lines sorts with. The Language dropdown picks whose rules apply - leave it on English unless the list is in another language.
Collation also handles case the way a dictionary does: apple and Apple are the same word and sort together instead of in two blocks. Tick Case sensitive only if capitals must count as different - and even then they stay adjacent.
The item9 and item10 problem
The second thing character comparison gets wrong is numbers inside text. item10 and item9 are decided at the fifth character, 1 against 9; 1 is lower, so item10 wins, and twelve files come back as 1, 10, 11, 12, 2, 3 - as anyone with a folder of numbered files has seen.
The fix is natural order: when a comparison reaches a run of digits on both sides, compare the run as one number instead of digit by digit. Then 9 beats 10 and the list reads item1, item2, item9, item10. That is the Read digits as numbers option, on by default because it is what people mean nearly every time.
How to sort a list alphabetically
- Open Sort Lines and paste your list, one item per line. For a run-on like red, green, blue, set Items are separated by to Commas.
- Leave Sort by on Alphabetical and Direction on A to Z. The result appears instantly.
- Set Language if the list is not in English - it only matters for accented or non-Latin characters.
- Tick Remove duplicates to collapse repeats. They are matched by the same case rule as the sort, so a case-insensitive sort treats Apple and apple as one.
- Copy the result, or download it as a text file.
A worked example. Paste seven lines - banana, Apple, apple, item10, item9, cherry, and Arger spelled with an A-umlaut - plus the blank line a copy-paste usually brings along. Out comes Apple, apple, Arger, banana, cherry, item9, item10. Apple and apple sit together in the order you typed them, because collation calls them equal and the sort is stable. Arger files under A instead of being flung past cherry. item9 precedes item10. The blank line is gone, and a note reads 7 items, 1 blank line dropped, so nothing vanished silently.
Sorting by something other than the alphabet
The Sort by menu covers the four other orders that come up:
- Number in the line sorts on the first number found, so Rent: 1,200.50 due compares against 3 apples numerically rather than as text; separators, decimals and minus signs are understood. Lines holding no number move to the end in their original order rather than being given a value of zero and scattered through the result.
- Line length sorts shortest to longest, counting characters as a reader sees them, so an emoji counts once. Equal-length lines fall back to alphabetical order, so the result is never arbitrary.
- Reverse current order flips the list without sorting it, for a log already in the order you want backwards.
- Random shuffle produces a genuine random permutation, for drawing names or randomising questions.
What sorting does and does not change
Every option that affects how items are compared builds a sort key behind the scenes and leaves the line alone. Ignoring case does not lowercase the output; ignoring a leading The - which files The Godfather under G, as a library would - does not delete the word. What comes out is what you put in, reordered.
Two things do change content, and both are reported. Each line is trimmed, so copied indentation does not decide the order. And blank lines are dropped - the one that quietly matters, because nearly every pasted list ends with a newline, and keeping it puts an empty row at the top. To strip repeats without reordering, use Remove Duplicate Lines.
When you actually want character order
Code-point order is the wrong default, but it is not useless - it is a different question. It is what sort gives you in a Unix shell under LC_ALL=C, what a database returns from ORDER BY on a binary collation, and how version control orders file names; comparing a list against one of those in dictionary order shows differences that are not really there. That is what the Code point (exact) mode is for, and it deliberately ignores the case and article options, because the point of asking for it is to reproduce something exactly.
Sort your list now
If a sort has handed you back Banana, Cherry, apple, it was comparing character codes and calling it alphabetical. Paste your list into Sort Lines for real dictionary order, numbers inside text read as numbers, and blanks and duplicates handled the way you would by hand - free, in your browser, and your list never leaves your device.
Frequently asked questions
- Why does my sorted list put all the capital letters first?
- Because the sort is comparing characters by their numeric code rather than alphabetically. Every capital ASCII letter has a lower code number than every lowercase one - A is 65 and a is 97 - so a plain sort produces all the capitalised words first, then all the lowercase ones. A collation-based sort treats apple and Apple as the same word and keeps them together, which is what a dictionary does and what Sort Lines does by default.
- How do I sort file names so that item9 comes before item10?
- Use natural order, which is the Read digits as numbers option and is on by default. Character-by-character comparison decides item9 against item10 at the 1 versus the 9 and files item10 first; natural order compares the whole run of digits as a number instead, giving item1, item2, item9, item10. It is the same rule your file manager uses when it lists a numbered series correctly.
- Can it sort a comma-separated list instead of one item per line?
- Yes. Set Items are separated by to Commas and paste the list exactly as you have it, such as banana, apple, cherry. Each item is trimmed of surrounding spaces, sorted, and joined back together with a comma and a space, so the result drops straight back into a sentence, a config value or a spreadsheet cell.