Why "sorted" is not one thing
Two people sort the same list and get different results, and neither is wrong. Sorting is not a property of a list. It is a comparison rule applied repeatedly, and the rule is a choice.
This tool sorts lines: one item per line, six orders. The six are not variations on a theme.
| Order | What it does | Reach for it when |
|---|---|---|
| A → Z | Browser-locale alphabetical, case and accent insensitive | Building an index, a glossary, a reference list |
| Z → A | The same comparison, reversed | Latest-first checklists |
| Natural / numeric | Alphabetical, but digit runs compare as numbers | Chapter lists, version numbers, file names |
| Shortest first | Sorts by visible character count, ascending | Spotting the one-line outliers in a long list |
| Longest first | The same, descending | Auditing which entries carry the most text |
| Most frequent first | Merges identical lines and counts them | Duplicate detection, log triage, keyword work |
There is no delimiter setting and no column mode. A pasted CSV sorts whole rows by their opening characters, and a tab-separated log sorts by its first field.
What the comparison quietly ignores
Alphabetical and numeric modes use the browser's own collation, which behaves in ways the word "alphabetical" does not prepare you for.
Case is ignored. apple, Apple, and APPLE compare as equal, so they land next to each other instead of in three separate blocks. That is what most people actually want from an alphabetical sort, and it is not what a byte-order sort does.
Accents are ignored too. resume and résumé compare as equal, as do cafe and café. Sorting names from several languages interleaves accented and unaccented spellings.
When two lines compare as equal, the ascending modes keep their original relative order: sort apple, Apple, APPLE and they come back in the sequence you pasted them in. The descending modes break that promise, because they sort upwards and then reverse the whole result, ties included. Whichever mode you pick, if tied entries seem to have swapped places, that is the reason.
The locale is your browser's, not a fixed one. Sorting Ä, Ö, and Z on a machine configured for German puts them where German puts them; the same list on an English-configured machine lands elsewhere. If the list matters, sort it once and keep that result.
Why Chapter 10 sorts before Chapter 2
Take the sample list: Chapter 10, Chapter 2, Introduction, Chapter 1, Introduction.
In A → Z you get Chapter 1, Chapter 10, Chapter 2, Introduction, Introduction. The comparison walks character by character, so Chapter 1 and Chapter 10 share their first eight characters and the shorter one wins. Nothing in the algorithm knows that 10 is a number.
Natural mode fixes that. Digit runs compare as numeric values, so you get Chapter 1, Chapter 2, Chapter 10, Introduction, Introduction. The same fix applies anywhere numbers hide inside labels: file9 before file10, v1.9 before v1.10, Section 3.2 before Section 3.10.
This is the most common reason a sorted list looks broken. A directory of versioned documents or a table of contents reads as nonsense in plain alphabetical order, and nobody notices until a reader does.
Sorting by length, to find the outliers
The two length modes ignore alphabetical order and compare visible character count, using grapheme clusters rather than bytes. An emoji counts as one character, not two.
The point is not a pretty list. It is to surface the entry that does not belong. Sort product names shortest first and the eye lands on the two-word outlier at the bottom. Sort a glossary longest first and the definitions three times the average length stand up and announce themselves. For an editor, that beats reading the whole file.
Ties keep their input order in Shortest first. Longest first sorts ascending and then reverses the whole array, so ties come out in reverse input order instead. Z → A works the same way. If you compare two sorted lists line by line and tied entries seem to have moved, that is why.
Frequency mode is a report, not a list
Frequency mode collapses identical lines. Each distinct line appears once, prefixed by its count and a tab, ordered by count descending.
So the sample becomes four lines: Introduction prefixed by 2, and each chapter prefixed by 1. The tied singles break alphabetically.
Two consequences. The result is not a list you can paste back, because every line starts with a count and a tab. And "identical" is exact: Apple and apple are different keys.
That makes frequency mode a decent duplicate detector and a poor one for human data. Run a messy name column through remove extra spaces first and the count becomes meaningful. If you want word-level frequency rather than line-level, the word counter has a panel for that.
The lines that are not what they look like
Three things produce results that look like bugs.
A trailing newline creates an empty line. Paste a list ending with a line break and the split produces a final empty item. In A → Z it sorts to the top, because nothing comes before something. Copy the list without the final newline.
Untrimmed lines sort before trimmed ones. A leading space is a character like any other, so apple lands before apple in the ascending alphabetical modes, and after it once the order is reversed. Clean the whitespace before sorting, not after.
Nothing is joined or flattened. If one item wrapped onto two lines in the source, the tool sorts the halves as two separate entries, and they will not end up next to each other.
Frequently Asked Questions
Why did my blank line end up at the top of the list?
Because an empty line sorts before every other line in the alphabetical modes, and a list pasted with a trailing newline produces one at the end of the input. Delete it, and the top of the list belongs to real data again.
Can I sort a spreadsheet column here?
Only by pasting the column as plain text, one value per line. Everything else in each row comes with it, so pasting whole CSV rows sorts rows by their opening characters rather than by a chosen field.
Why do accented names not sort the way my style guide says?
The comparison uses your browser's locale with case and accent folding, so the placement of accented letters depends on the machine. A house rule naming a specific ordering cannot be enforced here, so check the output and adjust by hand.
What is the difference between natural and alphabetical?
Alphabetical compares character by character, so a longer number sharing a prefix sorts before a shorter one: Item 10 before Item 2. Natural mode compares digit runs as numbers, so Item 2 comes first.
Does frequency mode delete the duplicate lines?
It merges them into one line with a count, which amounts to the same output plus a count prefix. For the values without numbers in front, use the duplicate line remover.
Is the order the same on another device?
No. The alphabetical comparison follows the locale of the machine doing the work, so a list sorted on your laptop can order differently on a colleague's. The length orderings avoid the problem entirely.
Sort the list you have, not the list you meant to paste
Spend ten seconds on the input before you choose an order: trim the whitespace, delete the trailing blank line, and pick one numbering format. Nearly every complaint about a sorted list traces back to the paste, not the sort: the blank line at the top, the duplicate that was never one, or the chapter list that turned into a lexicographer's joke.