Sort Lines

About Sort Lines Tool

Sort Lines is a multi-strategy line sorter with six ordering modes and four optional pre-processing steps. The six modes are: A-Z alphabetical (uses String.prototype.localeCompare() for accent-aware natural-alphabet ordering — 'á' sorts between 'a' and 'b' rather than after 'z'), Z-A reverse alphabetical, ascending length (sorts by Character count via String.length), descending length, Natural sort (the Intl.Collator with numeric:true option that orders 'file2' before 'file10' instead of after, matching the way Windows Explorer and modern file managers sort), and Random shuffle (Fisher-Yates algorithm using Math.random() for an unbiased permutation). Optional pre-processing applies before sorting: Trim Whitespace strips leading/trailing whitespace from each line via String.trim(), Remove Empty Lines drops blank or whitespace-only lines, Remove Duplicates keeps only the first occurrence of each unique line, and Case Sensitive toggles whether 'Apple' and 'apple' are considered different (default off, so case is folded). Typical workflows: alphabetize an unsorted list of customer names with proper handling of café and Müller, sort filenames naturally so v1.10 comes after v1.9 not after v1.1, randomize a list of trivia questions or playlist songs, build dedupe-and-sort pipelines for log analysis, and length-sort to find the longest/shortest entries in a dataset.

What is Natural sort and why does '10' come after '2' in alphabetical but before in Natural?

Alphabetical sort compares strings character-by-character: '1' (code point 49) < '2' (code point 50), so '10' is treated as starting with '1' and sorts before '2'. Natural sort detects embedded numeric substrings and compares them as numbers: in '10' it sees ten, in '2' it sees two, and 2 < 10, so '2' comes first. This is what humans expect for filenames (file2.txt before file10.txt), version strings (v1.9 before v1.10), and addresses (Apt 2 before Apt 10). Implemented via Intl.Collator with {numeric: true, sensitivity: 'base'}, which is the modern web standard and handles mixed alphanumeric correctly.

How does case sensitivity actually work — what about accented characters like 'café'?

When Case Sensitive is OFF (default), the sorter uses locale-aware case folding via localeCompare with sensitivity: 'base' — so 'Apple', 'APPLE', and 'apple' all sort as if identical, and accents like 'café' vs 'cafe' also fold to the same key. When Case Sensitive is ON, uppercase letters (code points 65-90) sort before lowercase (97-122), so 'Zebra' comes before 'apple'. For Vietnamese with full tones (à, ả, ã, á, ạ) the accent-folded mode treats all five 'a' variants as equivalent for sorting; accent-strict mode (not exposed in UI) would keep them distinct. To preserve Vietnamese tonal order strictly, sort externally with locale='vi'.

What is the difference between this tool and Unix `sort`?

Unix `sort` is the gold standard CLI and supports more flags (--field-separator, --key, --month-of-year, --human-numeric), handles arbitrarily large files via external merge sort, and is faster on multi-gigabyte inputs. This tool provides the most common 80% of use cases (alphabetical, reverse, natural, length, random, dedupe) in a browser UI with no install. For one-off sorts of a list pasted from email or Excel, the browser is faster (no file save needed). For a 10 GB log file, use `sort` or `sort -V` (version sort, which is similar to natural). The browser version is also locale-aware out of the box — `sort` defaults to bytewise unless you set LC_ALL=en_US.UTF-8.

In what order does it apply Trim, Remove Empty, Remove Duplicates, and the actual sort?

The pipeline is: 1) Trim Whitespace, 2) Remove Empty Lines, 3) Sort, 4) Remove Duplicates. This order matters. Trimming first means ' apple' and 'apple' are recognised as the same after trimming, so dedupe can find them. Removing empty before sort avoids them clustering at the top. Dedupe after sort guarantees adjacent duplicates are spotted (similar to Unix `sort -u` or `sort | uniq`). If you want duplicates kept but sorted by length, disable Remove Duplicates — order is otherwise identical.

How random is Random Shuffle — is it cryptographically secure?

It uses the Fisher-Yates shuffle algorithm with Math.random() as the source of randomness. This produces an unbiased uniform permutation (each of n! orderings has equal probability), which is mathematically correct for ordinary shuffling. However, Math.random() is NOT cryptographically secure — it is a deterministic pseudorandom generator that, in theory, could be predicted if you knew its internal state. For shuffling playlists, contest entries, trivia, or party games, it is perfectly adequate. For security-sensitive use cases (lottery draws, jury selection), use crypto.getRandomValues() in a custom script instead.

How does the tool handle very long inputs — does it scale to 1 million lines?

Yes, with caveats. JavaScript Array.sort() is O(n log n) on average using TimSort in Chrome/Edge/Firefox, so 1 million lines sort in roughly 1-3 seconds on a modern laptop. The browser textarea becomes the bottleneck — pasting 50+ MB of text can stall the UI. For datasets above 10 MB, prefer Unix `sort -u file.txt > out.txt` which streams from disk and handles arbitrarily large files via external merge sort. The 'Total Lines' counter shows how many lines you have before sorting, useful for sanity-checking that paste worked.

Is sorting done in the browser and is my text private?

Yes. All sorting runs in JavaScript via Array.sort(), Intl.Collator, and Fisher-Yates — no fetch() to a server, no analytics with content, no localStorage write. Open DevTools Network and click Sort to verify zero outbound requests. Safe for sensitive lists like customer email lists, employee rosters, internal hostnames, password generators output, or any data you should not upload.