Paste a list, pick an order, get it sorted. Case-sensitive or not, ascending or descending, with natural sort for filenames and version strings.
A free, in-browser tool that takes a block of text, splits it on line breaks, sorts the lines, and gives you the result. No signup, no upload, nothing leaves your machine. Paste, click, copy.
It is the equivalent of running sort on the command line, except you do not have to fight with LC_COLLATE, the way macOS ships an older BSD sort, or the fact that Windows does not have sort at all unless you install Git Bash. Three checkboxes here cover the cases you actually want: ascending or descending, case-sensitive or not, and natural sort for filenames like file2 coming before file10.
If you have ever pasted a list of dependencies into package.json and wondered why npm reordered them on the next install, this tool reproduces what npm 7+ does so the diff is empty when CI runs.
Under the hood the tool uses the browser's Intl.Collator API. That gives you a Unicode-aware compare function the way the Unicode Collation Algorithm (UTS #10) defines it, not a raw codepoint compare. The practical difference: Intl.Collator knows that é sorts next to e, that German ß compares equal to ss at the primary level, and that uppercase and lowercase only differ at the tertiary level.
Lexicographic sort and locale-aware sort are not the same thing. A pure codepoint sort (what LC_ALL=C sort gives you) puts every uppercase letter before every lowercase letter, because A is U+0041 and a is U+0061. A Unicode default-collation sort interleaves them: A < a < B < b < C. We default to the locale-aware order because it matches what people expect when they hit Sort A-Z in Excel or Google Sheets. Tick the case-sensitive box to fall back to the codepoint-style ordering.
Natural sort is the third axis. With it on, file2.log comes before file10.log because the embedded numbers are compared as numbers, not character by character. Wikipedia has a clean explanation of natural sort order if you want the background. The implementation uses Intl.Collator's numeric: true option, which is the same primitive Finder, Windows Explorer, and recent versions of GNU sort -V use.
One pane in, one pane out. The whole thing runs locally; close the tab and your text is gone.
Drop your list into the editor, one item per line. Trailing blank lines are fine. CRLF and LF endings both work; the output normalises to LF unless you tell it otherwise. The Sample button fills the editor with a small mixed list if you want to see all three options in action first.
Choose Ascending or Descending, toggle Case-sensitive if you need Apple to come before banana, and turn on Natural sort when filenames or versions are in the mix. Remove blank lines drops empty rows before sorting; Remove duplicates collapses repeats.
Hit Sort. The result lands in the output pane. Use Copy to put it on the clipboard, or Download to save it as a .txt file. The line count in the header shows how many rows came out, which is useful when you turned on dedupe and want to know how many duplicates were removed.
Marketing pastes a CSV of subscriber emails into the campaign tool, but the list arrived in signup order. Sort it alphabetically here first, with case-insensitive on (since email local-parts are case-insensitive in practice), then dedupe. The campaign tool's import will be faster and you will spot a typo'd domain like gmial.com immediately because it sits next to the legitimate gmail.com block.
Some teams enforce alphabetical class names in class="..." attributes so PR diffs stay clean. Paste the value, sort, paste it back. The same trick works for HTML attribute ordering when a linter complains, or for sorting Tailwind utility classes by hand when you do not have prettier-plugin-tailwindcss installed in the repo.
A .gitignore that everybody appends to becomes a junk drawer. Sort it alphabetically once, commit that, and from then on additions land in obvious places and the diff makes sense to reviewers. The same applies to .dockerignore, .eslintignore, and the files array in tsconfig.json when teams keep one.
Slack and Discord paste lists with weird ordering, half-empty lines, and duplicates from people who said the same thing twice. Paste, turn on Remove blank lines and Remove duplicates, sort. You get a clean ordered list to drop into your task tracker.
ISO 3166 country codes, IATA airport codes, ISO 4217 currency codes: these all live in lookup files that benefit from being sorted. Natural sort is unnecessary here because the codes are fixed-width, but case-insensitive matters because some sources mix USD with usd. Sort, dedupe, paste back into the lookup table.
package.json dependency keys are alphabetised by npm 7+ on every install, but if you are editing on a project still pinned to npm 6 (or yarn 1) the order will not change automatically. Paste the dependency keys, sort A-Z, and paste back. Your next PR will not have a 200-line reorder commit on top of the actual change.
A short cheat sheet for the sort options this tool exposes and the edge cases they cover.
| Topic | What this tool does |
|---|---|
| Lexicographic vs collation | Lexicographic (codepoint) sort orders by raw Unicode value: A (U+0041) before a (U+0061). Collation sort follows the Unicode Collation Algorithm and interleaves cases. This tool uses collation by default; tick Case-sensitive for codepoint order. |
| Case sensitivity | Default is case-insensitive: apple, Apple, and APPLE compare equal. Switch to case-sensitive for A < a < B < b ordering at the tertiary collation level, or for raw codepoint order when combined with the C locale. |
| Natural sort | When on, file2 < file10 because 2 and 10 are compared as numbers. When off, file10 < file2 because 1 (U+0031) compares less than 2 (U+0032) character by character. Use it for filenames, version strings, and any list with embedded numbers. |
| Locale awareness | Sort respects the page's locale so é orders next to e in French, German ä sorts as ae in DIN 5007-2 phonebook order, and so on. The unix sort command does the same thing if LC_COLLATE is set; LC_ALL=C sort falls back to codepoint order, which is faster but treats accents as alien letters. |
| Blank-line handling | Empty lines sort before any non-empty line in ascending order, so they cluster at the top. Tick Remove blank lines to drop them entirely. A trailing newline at end of input is kept as-is so the output round-trips through cat and similar tools. |
| Stability | The sort is stable: lines that compare equal under your settings keep their original relative order. This matters when you sort by a prefix or under case-insensitive mode and want the input order preserved within a tie group. Both V8 (Chrome, Edge, Node) and SpiderMonkey (Firefox) guarantee stable Array.prototype.sort since 2019. |
| Line endings (LF vs CRLF) | Input is split on \r\n, \n, and \r. Output is joined with \n by default so it pastes cleanly into Linux and macOS workflows. If you need CRLF for a Windows tool, paste the result into a Windows-aware editor and save with the line ending you want. |
| Encoding | Input is treated as UTF-8 (text in the browser is already decoded). A leading UTF-8 BOM is preserved on the first line if present; if you want it stripped, the whitespace-cleaner sister tool removes it. |
Locale-aware ascending, using the browser's Intl.Collator with the page locale. That means A < a < B < b the way Excel and Google Sheets sort, not the raw codepoint order where every uppercase letter sorts before every lowercase one. If you want the codepoint order, tick the Case-sensitive option, which switches the collator to a strict tertiary-level compare and gives you the same ordering as LC_ALL=C sort.
Case-insensitive by default. Apple, apple, and APPLE all collapse to the same key, so they cluster together in the output and their relative order is whichever appeared first in the input (the sort is stable). Tick Case-sensitive to separate them, in which case APPLE, Apple, and apple sort as three distinct values according to the Unicode default-collation tertiary level.
Yes. Turn on the Natural sort option and embedded numbers are compared as numbers, so file2.log comes before file10.log, and v1.9 comes before v1.10. The implementation is the numeric: true option on Intl.Collator, the same primitive macOS Finder and Windows Explorer use to order filenames.
Yes. Pick Descending in the order toggle. The sort runs in ascending order first, then reverses, which preserves stability across equal keys: if two lines compare equal under your case and natural-sort settings, they keep their original relative order even after the reverse. That matters when you are sorting on a partial key like the first column of a TSV.
By default both are kept. Sorting is stable, so duplicates stay in their original relative order, and blank lines cluster at the top in ascending order (they sort before any non-empty string). Tick Remove blank lines to drop them before sorting, and Remove duplicates to collapse equal lines into one. For a dedicated dedupe pass with more options, use Remove duplicate lines.
Up to about 100,000 lines runs sub-second in the browser. Past 500,000 lines you start to feel it, mostly because rendering the result pane (not the sort itself) gets expensive. For multi-million-line files, the unix sort command with LC_ALL=C sort -u file.txt is faster and runs out-of-core. The GNU coreutils sort manual covers the flags worth knowing.
Your text never leaves your browser. The split, the compare, and the join all run locally. No analytics on your input, no logs, no server round-trip. The compare itself is the browser's native Intl.Collator, which implements the Unicode Collation Algorithm (UTS #10). If you want background reading, Wikipedia has a solid overview of sorting algorithms generally.