DEV Community

withuse
withuse

Posted on Originally published at uuid.withuse.io AI-assisted

I measured whether .NET Guid sorting is broken. It isn't.

#dotnet #csharp #database #uuid

"Guid sorting in .NET is weird" is a claim you run into often enough that I wanted a number for it. So I measured CompareTo directly.

It sorts in logical value order. The claim is wrong, and the thing people are actually hitting is something else.

You need a sample that can tell the two hypotheses apart

This is the part that took me two attempts. .NET stores the first three groups of a Guid in little-endian internally, so to distinguish "sorts by string order" from "sorts by raw byte order" you need values where those two orders disagree. Most hand-written samples do not.

value                                   ToByteArray() first 4 bytes
00000100-0000-0000-0000-000000000000    00-01-00-00
00000001-0000-0000-0000-000000000000    01-00-00-00
01000000-0000-0000-0000-000000000000    00-00-00-01
00010000-0000-0000-0000-000000000000    00-00-01-00
Enter fullscreen mode Exit fullscreen mode

Sorted by string, those come out in one order. Sorted by raw bytes, exactly the reverse. Now the test means something.

Result 

CompareTo order == string order       True
CompareTo order == raw byte order     False
sample distinguishes the hypotheses   True
Enter fullscreen mode Exit fullscreen mode

That third line matters as much as the other two. Without it you cannot tell a passing test from a test that could not have failed.

So Guid.CompareTo is independent of the ToByteArray() layout. The folk claim conflates the comparer with the byte layout.

The real trap is the byte layout

ToByteArray() does not return RFC 9562 network byte order. The first three groups come back reversed:

Guid        00112233-4455-6677-8899-aabbccddeeff

default     33-22-11-00-55-44-77-66-88-99-AA-BB-CC-DD-EE-FF
bigEndian   00-11-22-33-44-55-66-77-88-99-AA-BB-CC-DD-EE-FF
Enter fullscreen mode Exit fullscreen mode

Look at the first four bytes. 33-22-11-00 against 00-11-22-33. Groups one, two and three are byte-swapped; the last two groups are not.

Since .NET 8 you can ask for RFC order explicitly with ToByteArray(bigEndian: true).

Where it actually bites

  • Python gives you both and names them: .bytes is RFC order, .bytes_le is the .NET default layout
  • SQL Server's uniqueidentifier comparison uses yet another order, which is where most of the "sorting is weird" stories actually come from
  • Anywhere you write a Guid to bytes and read it back with a different library

So

Sorting is not broken. The layout differs when you serialise. It only matters when a value crosses a system boundary, and at that boundary you can just say which order you want.

Verified

.NET 10.0.400, run 2026-10-08. An earlier run on 2026-09-14 gave identical results on .NET 10.0.11.

Full write-up, including the Python and SQL Server side: https://uuid.withuse.io/uuid-vs-guid/

Top comments (0)