Sort Lines Alphabetically
Last updated: 27 June 2026
Reviewed by Gavin Meiring, Lead research and primary author · Doctoral Candidate (Corporate Governance) · Research and drafting assisted by AI
- Alphabetical order is an ancient technology: the Library of Alexandria's catalogue, Callimachus's 'Pinakes' of the 3rd century BC, arranged authors alphabetically for the first time.
- The quicksort algorithm behind most sorting utilities was invented in 1959 by British computer scientist Tony Hoare, who came up with it while working on machine translation in Moscow.
- Alphabetical order is not universal: German sorts 'ä' as 'a', Swedish puts 'å' at the end of the alphabet, and Spanish treats 'ñ' as its own letter after 'n' — so the 'correct' sort order depends on your language.
Sort Lines Tool
A sort lines tool arranges the lines of a text block into alphabetical, numerical, or reverse order at the click of a button. It is used by developers, data analysts, writers, and content managers who need to organise lists of items, sort code imports, alphabetise reference lists, or tidy up structured text data.
How to Use the Sort Lines Tool
- Paste your list or text block into the input area, with each item on a separate line.
- Select your sort order: A to Z (ascending), Z to A (descending), or numerical order.
- Choose whether the sort should be case-sensitive or case-insensitive.
- Optionally enable "remove duplicates" to deduplicate as part of the same operation.
- Click sort and copy the output.
The Formula
Sorting algorithms compare items pairwise and rearrange them according to a comparison function. The most common algorithm for general-purpose text sorting is a variant of merge sort or Timsort, both of which run in O(n log n) time in the average case.
For alphabetical sorting, the comparison function uses Unicode code point order by default, which means uppercase letters sort before lowercase ones (case-sensitive mode). In case-insensitive mode, both strings are converted to the same case before comparison, so "Banana" and "banana" are treated as equal.
For numerical sorting, the tool parses each line as a number before comparing, ensuring that "10" sorts after "9" rather than before it (which would happen in a pure alphabetical sort, since "1" comes before "9" in character order).
Real-World Example
A developer needs to alphabetise the import statements at the top of a Python file for code review compliance. The imports are in random order:
import requests
import json
import os
import sys
import re
Pasting into the sort lines tool with ascending, case-insensitive sort produces:
import json
import os
import re
import requests
import sys
The developer replaces the original block with the sorted version in seconds.
Practical Applications of Line Sorting
Sorted lists are easier to scan and maintain. In Python and JavaScript projects, many style guides require sorted import statements so that reviewers can quickly confirm no duplicates exist. In content work, alphabetised glossaries, bibliographies, and tag lists are standard practice. For data processing, sorting a list of values before deduplication or comparison reduces the complexity of subsequent operations. Sorting is also used to prepare text for binary search, which locates items in O(log n) time rather than the O(n) time required to scan an unsorted list.
Frequently Asked Questions
What is the difference between case-sensitive and case-insensitive sorting? Case-sensitive sorting places all uppercase letters before lowercase letters (because uppercase letters have lower Unicode values). "Banana" would appear before "apple" in case-sensitive ascending order. Case-insensitive sorting ignores capitalisation, treating "Banana" and "banana" as equivalent and placing them alphabetically alongside other B words.
Can I sort numbers correctly with this tool? Alphabetical sorting treats "10" as less than "9" because it compares character by character ("1" < "9"). Numerical sort mode parses each line as a number first, producing the mathematically correct order: 1, 2, 9, 10, 11. Always use numerical mode when sorting lists of numbers.
Does sorting preserve blank lines? This varies by tool. Some implementations treat blank lines as empty strings that sort to the top, while others strip blank lines from the output. Check the result and remove unwanted blank lines manually if necessary.
Can I sort by a specific column rather than the whole line? Standard line-sort tools sort the entire line as a unit. For column-based sorting, use a spreadsheet application or a command-line tool such as the Unix "sort" command with a key specification.
The same ten lines under two comparison rules
The default comparison in most line sorters is the Unicode code point, which for Basic Latin text is the same order as ASCII. Digits run from 48 to 57, uppercase letters from 65 to 90, and lowercase letters from 97 to 122. Accented Latin letters sit above all of those. The e with an acute accent is 233, so it sorts after every plain lowercase letter.
That produces an order that surprises people. The table below sorts one list twice.
| Rank | Code point order | Case-insensitive order |
|---|---|---|
| 1 | 10 | 10 |
| 2 | 2 | 2 |
| 3 | 9 | 9 |
| 4 | Banana | apple |
| 5 | Cherry | Banana |
| 6 | Zebra | banana |
| 7 | apple | cafe |
| 8 | banana | café |
| 9 | cafe | Cherry |
| 10 | café | Zebra |
Code point order puts Zebra before apple, because 90 is below 97. It also puts the digits first, so 10 sorts before 2. Case-insensitive order folds the case away, so the two forms of banana end up next to each other and apple moves to the front of the letters.
The accented pair is worth a second look. Folding case alone leaves café after cafe, because 233 is above 101 at the fourth character. Folding the accent as well makes the two compare equal, and then the tie-break decides which comes first. That is why two tools can both claim to sort case-insensitively and still disagree about a word list with accents in it.
Numbered names sort wrongly until the numbers are parsed
File names ending in digits show the same problem in a form that costs real time. Comparing characters means comparing the character after the shared prefix first, and the digit 1 is 49 while the digit 2 is 50. Every name beginning file1 therefore precedes every name beginning file2.
| Alphabetical order | Numerical order |
|---|---|
| file1 | file1 |
| file10 | file2 |
| file100 | file10 |
| file11 | file11 |
| file2 | file20 |
| file20 | file100 |
The alphabetical column is not wrong. It is a correct character-by-character sort, and it is what a reader gets from any tool that compares strings. Numeric mode parses the digits and compares 1, 2, 10, 11, 20 and 100 as numbers, which is the order a reader expects. When a list mixes numbered and unnumbered lines, the two modes disagree on the numbered ones only, so sorting numerically is safe for a list of release names, ticket numbers or chapter headings.
A deduplication pass is cheap once the list is sorted
Duplicates end up next to each other after a sort, so removing them takes a single pass with one comparison per adjacent pair. A thousand lines need 999 comparisons and a million lines need 999,999. Sorting is the expensive part.
| Lines | Comparisons for a general comparison sort | Comparisons for the adjacent deduplication pass | Ratio |
|---|---|---|---|
| 1,000 | 9,966 | 999 | 10 |
| 10,000 | 132,877 | 9,999 | 13 |
| 100,000 | 1,660,964 | 99,999 | 17 |
| 1,000,000 | 19,931,569 | 999,999 | 20 |
The sort column is n multiplied by the base-2 logarithm of n, which is the bound for a general comparison sort in the average case. The measured count for a real algorithm is usually lower. Python's sorted function uses Timsort, which looks for stretches that are already in order and merges them, so a list that is half sorted costs far less than the table suggests. The table is the ceiling, not the expectation.
When the sort order belongs to the machine rather than the reader
Byte order and collation order are different questions. A byte comparison answers which string is numerically smaller. A collation answers where a reader expects to find a word in a list, and the Unicode Collation Algorithm handles that second question by comparing letters before accents and case.
A short name list separates the two rules.
| Name | First code point | Rank in code point order | Rank in collation order |
|---|---|---|---|
| Adeyemi | 65 | 1 | 1 |
| Zoë | 90 | 2 | 4 |
| de Vries | 100 | 3 | 3 |
| Åberg | 197 | 4 | 2 |
Code point order puts Zoë second and Åberg last. Collation order puts Åberg second, next to the other names beginning with an A, and Zoë last. Neither list is incorrect. The first is what a byte comparison produces, and the second is what a telephone directory does.
The choice matters in three places. Sorting a list for display should follow collation, because the reader is human. Sorting to build a lookup key, an index or a comparison between two systems should follow bytes, because both sides must agree without a shared collation library. Sorting to deduplicate works under either rule, as long as the whole list uses the same one.
Stability, and why the tie-break decides the output
Two lines can compare equal. Under a case-insensitive rule the strings Banana and banana are the same key, and the comparison function has no way to separate them. What happens next depends on whether the sort is stable.
A stable sort leaves equal items in the order they arrived. That property is what lets a two-key sort be built from two single-key passes: sort on the least important key first, then on the most important one, and the second pass keeps the first pass's order inside each group. Almost every general-purpose library sort is stable, including the one behind Python's sorted function. The takeaway for line sorting is that a reader can predict the result of two consecutive sorts, and a tool that says which algorithm it uses has answered the question.
The Unix sort command is the exception worth knowing. Without the stable flag it falls back to comparing whole lines when the requested keys tie, so equal keys come out in byte order rather than in input order. The stable flag disables that last-resort comparison. On a small list, either behaviour looks fine. On a report of five hundred lines, an unstable pass moves two equal-key rows and the next run of the same report produces a diff.
Also try these free tools: