Sort IP Addresses
the Way They Actually Order
Paste a list and get it back in numeric order — IPv4, IPv6, CIDR blocks and host:port pairs together, straight out of a log or a firewall export. Alongside it you get the ordering a plain text sort would have produced, with every entry that moved highlighted, so you can see exactly how wrong Excel was about your own data.
0
Sorted
0
Moved vs text sort
0
Duplicates removed
0
Not recognised
What a text sort gives you — Excel, sort A–Z, ORDER BY on a text column
Numeric order — correct
Quick Answer: Why Do IP Addresses Sort Wrong?
Because software compares them as text, character by character, so 1 beats 9. That puts 10.216.11.101 after 10.216.109.23. They have to be compared as numbers, and nothing in a spreadsheet does that by default.
Robert Harrison
OSINT and Network Utility Expert
Robert works on network diagnostics and the practical end of IP tooling — the conversions, lookups and calculations that sit underneath everything else.
Everybody knows text sorting mangles IP addresses. What gets underestimated is how easy the damage is to miss. The example I keep coming back to is from a real spreadsheet: 10.216.11.101 landing after 10.216.109.23. Both begin 10.216, they sit next to each other on screen, and nothing looks wrong until you count.
So the tool shows both orderings side by side and highlights every entry that moved. On a short list that is a curiosity. On four hundred rows out of a firewall export it is usually a surprise, and occasionally it is the reason a rule was not doing what somebody thought it was.
Last reviewed 24 August 2026 · Runs entirely in your browser · Nothing you paste is sent anywhere
View all articles by Robert HarrisonWhy Does a List of IP Addresses Come Out in the Wrong Order?
Because almost everything sorts them as text. That is a lexicographic comparison — the same rule an alphabetical sort uses on words. It walks left to right and stops at the first character that differs, so 1 beats 9 and the comparison ends there. It never learns that the thing it is comparing is a number.
A numeric sort compares the value instead. Each of the four octets in IPv4, or the eight hextets in IPv6, is read as a number and weighed by its position. That is the ordering a routing table uses, and the one every other tool on this page assumes.
The textbook example is 10.0.0.10 landing above 10.0.0.2, and it is a fair illustration. It is also unrealistically obvious. Here is one from an actual spreadsheet:
10.216.11.101 sorts after 10.216.109.23.
Both start 10.216. On screen they are neighbours in a column of similar-looking addresses. There is no visual cue that anything is out of place — the break is in the third octet, four characters in, and the eye slides past it. That is what makes this bug expensive: not that it happens, but that a sorted-looking list is trusted.
Sorting is also where validation happens
A list that has to be ordered numerically has to be parsed first, and parsing is validation whether you asked for it or not. A typo like 192.168.1.256 or a stray hostname cannot be given a numeric position, so it surfaces instead of sitting quietly in the middle of a rule set. Those entries are counted and listed rather than dropped.
Where the damage actually lands
A scrambled list is annoying in a report and dangerous in three specific places.
- Reading either direction. Ascending order is the default because it matches how ranges are written and how a routing table reads. Descending is one click, and is what you want when the question is which addresses are highest in a block.
- Port pairs from a log. A
netstatdump or an access log gives you10.0.0.5:443, not a bare address. Sorted by address and then by port, repeated connections to one host group together instead of scattering. - Deduplication by eye. Duplicates only sit next to each other if the sort was right. In a text-sorted list they scatter, and a list assembled from several exports quietly keeps its repeats.
- Range spotting. Nobody can see that thirty consecutive addresses in a log belong to one block when they are interleaved with unrelated ones.
- Rule ordering. Covered below, and the only one of the three where a wrong order changes what the system does rather than how it reads.
The underlying reason is the same one that makes storing addresses as integers worth doing in a database: an address is one number, and every problem here comes from treating it as a string of characters instead.
How Do You Sort IP Addresses in Excel or Google Sheets?
With a helper column. There is no setting, no format and no built-in function — Excel has no concept of an IP address and treats every one of them as text. Every published method works around that rather than fixing it.
The short formula: pad every octet to three digits
This is the one worth knowing, because it is the only approach that fits on a screen. Pad each octet with leading zeros so all four are the same width, and a plain A–Z text sort suddenly comes out right:
Fill it down, sort the sheet by column B, then delete column B. The same formula works in Google Sheets unchanged.
The alternatives, and why they are worse
A numeric sort key — multiplying each octet by its place value into one integer — produces the same ordering. In a single Excel cell that formula runs to several hundred characters and is unreadable, unmaintainable and quietly wrong if anyone edits it. Microsoft's own community answer for this question is exactly that: one enormous line.
A VBA macro is cleaner if you sort addresses regularly, and pointless if you do it twice a year. Splitting into four columns with Text to Columns works too and destroys the original column, so it needs a copy first.
None of them handle IPv6. The padding trick assumes four fixed octets, which an IPv6 address does not have — it has eight hexadecimal groups and a :: shorthand that has to be expanded before anything can be padded. Excel guidance on this is unusually blunt: standard IP sorting methods do not cover IPv6, and specialised software or a script is what to use. The sorter above does IPv6 without either.
And on the command line, sort -V handles IPv4 correctly for free. It is a version sort rather than an address sort, but the two agree on dotted quads.
When Does the Order Change What the Rules Do?
Everywhere that evaluation stops at the first match, which is most places. iptables walks a chain top to bottom. Cloud firewall rules carry a priority and the lowest is evaluated first — Google documents its App Engine rule set exactly that way, with a catch-all at the end for anything unmatched. Most WAF rule sets and router ACLs work the same.
The same applies to an allowlist or a blocklist written as ordered rules rather than as a set. A set has no order and nothing can shadow anything; an ordered rule list can hide an entry completely, and looks identical either way until you sort it.
Which means position is not presentation. A rule below one that already covers it never runs.
Sorting by network address and then by prefix length is what makes that legible. Every general block lands immediately above the specific entries inside it, so an exception buried in the wrong place stops being invisible. The sorter above orders CIDR that way by default.
Reading a log by volume
The other routine use is log analysis. Sorted addresses group naturally, so a single noisy subnet shows up as a run of adjacent lines rather than as scattered entries that never add up to a pattern. If the addresses came out of an access log and you want to know which are genuine search crawlers before you act on any of them, the bulk bot checker takes 200 at a time.
Once the list is sorted, consecutive runs are worth collapsing into prefixes. The range to CIDR converter turns a first and last address into the blocks that cover them, and the CIDR calculator expands a prefix back into its range, which is the check to run in the other direction — a rule written as a block is only correct if the block is the one you meant.
What this tool cannot do
It orders a list. Everything past that is a different job.
IPv4 and IPv6 are grouped, not interleaved
One is 32 bits and the other 128, so there is no honest single ordering across both. IPv4 comes first, then IPv6, each sorted properly inside its group and labelled so the split is visible.
It does not merge or aggregate
Sixteen consecutive addresses stay sixteen lines rather than collapsing into one prefix. Sorting makes those runs visible, which is the step before aggregating them, not the same step.
Order is not correctness
A correctly sorted rule set can still be wrong. Sorting reveals a specific entry sitting under a block that swallows it; deciding what to do about that is a judgement the tool cannot make.
Ports are kept, not stripped
A host:port pair sorts by address first and port second, and the port stays in the output. IPv6 needs the bracketed form — [2001:db8::1]:443 — because a bare colon already belongs to the address.
Unparseable lines are kept aside
Hostnames, comments and malformed entries cannot be ordered numerically, so they are counted and listed at the end rather than dropped. A list that quietly lost rows is worse than one that did not.
To see why an address is one number rather than four, the binary converter lays out all thirty-two bits, and the subnet calculator works out what a mask actually covers.
And once you know which addresses matter, a geolocation and network lookup tells you who they belong to.
Frequently asked questions about sorting IP addresses
What is an IP address sorter?
A tool that orders a list of addresses by their numeric value rather than as text. That distinction is the whole point: an IP address sorter knows that 10.0.0.2 is smaller than 10.0.0.10, where an alphabetical or lexicographic sort — the kind a spreadsheet does — compares character by character and gets it backwards. This one also validates each entry, handles IPv4, IPv6, CIDR and host:port, and can remove duplicates in the same pass.
How do I sort IP addresses correctly?
Compare them as numbers, not as text. An address is really one 32-bit number written with dots for readability, so 10.0.0.2 is smaller than 10.0.0.10 even though the text 10.0.0.10 sorts first. Paste your list above and it is ordered numerically, with the text ordering shown alongside so you can see which entries moved.
Why does Excel sort IP addresses in the wrong order?
Because Excel has no built-in IP type. It sees 10.216.11.101 as a string of characters and compares them one at a time, so 1 beats 9 and the address lands after 10.216.109.23. Both start 10.216, which is why this particular mistake is so easy to miss. Every fix involves a helper column — there is no setting that makes it work.
What is the Excel formula to sort IP addresses?
The short one pads each octet to three digits so that a text sort comes out right: =TEXT(LEFT(A1,FIND(".",A1)-1),"000") repeated for each octet and joined with dots. Sort by that helper column, then delete it. It works because 010.216.011.101 and 010.216.109.023 compare correctly once every octet is the same width. Numeric-key formulas do the same job and run several hundred characters long.
Can Excel sort IPv6 addresses?
Not with the standard methods. IPv6 is longer, hexadecimal and uses :: compression, so a padding formula would have to expand the address first. Excel guidance generally recommends specialised software or a script rather than a formula. The sorter above handles IPv6 alongside IPv4 without either.
Does the order of firewall rules matter?
Yes, and this is the case where sorting is correctness rather than tidiness. Most firewalls, ACLs and WAFs evaluate rules in order and stop at the first match — Google App Engine documents its rules as carrying a priority, lowest evaluated first, with a catch-all at the end. A specific deny placed after a broad allow that covers it will never run. Sorting the list numerically is how you see that.
How do you sort IPv4 and IPv6 in the same list?
They are different sizes — 32 bits against 128 — so there is no single number that orders them together meaningfully. The convention this page follows is to group IPv4 first, then IPv6, each sorted numerically inside its own group. The output labels which is which so nothing is ambiguous.
How are CIDR blocks sorted?
By network address first, then by prefix length, so a block always appears immediately before the more specific blocks inside it. 10.0.0.0/8 comes before 10.0.0.0/16, which comes before 10.0.0.5. That is the order you want when reading a rule set, because it puts every general rule directly above the exceptions it contains.
Does it handle addresses with a port, like 1.2.3.4:80?
Yes, in both families. A bare host:port works for IPv4, and IPv6 needs the bracketed form [2001:db8::1]:443 because a plain colon is already part of the address. The port stays attached in the output and acts as a tiebreaker, so 1.2.3.4:80 sorts above 1.2.3.4:443 rather than landing wherever the input left it. This matters because most real lists come out of a log, a netstat dump or a firewall export, and all three carry ports.
Will it remove duplicates?
If you switch it on. Duplicates are common in lists assembled from several sources and a sorted list is where they become visible, since identical entries end up adjacent. The count of what was removed is shown rather than hidden, because a list that quietly shrank is worse than one that did not.
Is my list uploaded anywhere?
No. The sorting runs entirely in your browser in JavaScript. Nothing is sent to a server, nothing is logged, and you can confirm that by opening the network tab while you use it. That matters for lists of internal addresses, which are the ones people most often need to sort.
How many addresses can it handle?
Up to 50,000 lines in a run, which sorts in well under a second. You can drop a .txt or .csv file onto the box rather than pasting. Anything beyond that is better handled with sort -V on the command line, which does version sorting and gets IPv4 right for free.
Related IP tools
The rest of the list-wrangling toolkit.
Browse the full set on the TrustMyIP tools directory.
Last updated 24 August 2026 · Runs in your browser · Nothing you paste is sent anywhere