Why Is My UUID to Base64 Result Different in C#, Java & Python?

If you have ever tried converting a UUID into a compact Base64 string across a microservice architecture built with C# (.NET), Java, and Python, you have almost certainly run into a frustrating bug:

You take the exact same UUID string, convert it to Base64 in C#, Java, and Python, and get two completely different Base64 strings.

Here is the quick, direct answer:

• The Base64 algorithm is identical in every language. Base64 is defined by RFC 4648 and works exactly the same way everywhere.
• Base64 does not encode UUID text; it encodes raw binary bytes.
• The difference comes from the 16 bytes being encoded:
  • Java and Python (uuid.bytes) serialize UUIDs in Big-Endian (Network Byte Order), matching the canonical hexadecimal string from left to right.
  • C# (.NET Guid.ToByteArray()) historically serializes GUIDs in Microsoft COM Mixed-Endian format, which reverses the byte order of the first three components (the first 4 bytes, then 2 bytes, then 2 bytes).
  • Python (uuid.bytes_le) produces the Microsoft mixed-endian format.

┌────────────────────────────────────────────────────────────────────────┐
│               THE UUID TO BASE64 DISCREPANCY EXPLAINED                 │
├────────────────────────────────────────────────────────────────────────┤
│ Canonical UUID:   00112233-4455-6677-8899-aabbccddeeff                 │
├────────────────────────────────────────────────────────────────────────┤
│ Java / Python:    00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff      │
│                   └───► Base64: ABEiM0RVZneImaq3zN3u/w==               │
├────────────────────────────────────────────────────────────────────────┤
│ C# .NET Default:  33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff      │
│                   └───► Base64: MyIRAFVEd2aImaq3zN3u/w==               │
└────────────────────────────────────────────────────────────────────────┘

In this comprehensive engineering guide, we will break down why this byte-order mismatch happens, the math behind the byte flipping, how to inspect your raw bytes, and how to make C#, Java, and Python produce 100% interoperable Base64 UUIDs.

---

1. UUID Text vs. 16 Binary Bytes

A UUID (Universally Unique Identifier) or GUID (Globally Unique Identifier) is fundamentally a 128-bit integer (16 bytes).

When displayed on a screen or sent in JSON, it is written as a 36-character canonical hexadecimal string:

00112233-4455-6677-8899-aabbccddeeff

This string consists of five hyphen-separated groups:

• Group 1 (4 bytes / 8 hex chars): 00112233
• Group 2 (2 bytes / 4 hex chars): 4455
• Group 3 (2 bytes / 4 hex chars): 6677
• Group 4 (2 bytes / 4 hex chars): 8899
• Group 5 (6 bytes / 12 hex chars): aabbccddeeff

How Base64 Conversion Works

To compress a 36-character UUID string into a compact 22- or 24-character token, developers encode its 16 raw binary bytes using Base64:

$$\text{16 bytes} \times 8 \text{ bits} = 128 \text{ bits} \xrightarrow{\text{Base64 (6 bits/char)}} 22 \text{ characters} + 2 \text{ padding chars} \ (==) = 24 \text{ chars}$$

Because Base64 converts groups of 6 bits into ASCII characters, if the 16 bytes entering the encoder are in a different sequence, the resulting Base64 string will be completely different.

If you want to test and verify compact encodings interactively, check out our free Base64 UUID Generator.

---

2. Big-Endian vs. Little-Endian in Simple Terms

To understand why the byte arrays differ, we need to look at Endianness (byte ordering in memory):

┌────────────────────────────────────────────────────────────────────────┐
│                       BIG-ENDIAN VS LITTLE-ENDIAN                      │
├───────────────────┬────────────────────────────────────────────────────┤
│ Big-Endian        │ Most significant byte stored FIRST (left to right).│
│ (Network Order)   │ Natural human reading order. Used by RFC 9562,     │
│                   │ Java, network protocols, and standard Python.      │
├───────────────────┼────────────────────────────────────────────────────┤
│ Little-Endian     │ Least significant byte stored FIRST. Used by x86,  │
│ (x86 Hardware)    │ x64, and ARM processors for fast CPU arithmetic.   │
├───────────────────┼────────────────────────────────────────────────────┤
│ Mixed-Endian      │ A combination of little-endian fields and          │
│ (Microsoft GUID)  │ big-endian fields. Used by C# Guid.ToByteArray().  │
└───────────────────┴────────────────────────────────────────────────────┘

When RFC 4122 and RFC 9562 defined UUIDs, they mandated Big-Endian (Network Byte Order) for all 16 bytes.

However, Microsoft originally designed Windows COM GUIDs as a C-style struct composed of native integer types:

// Traditional Microsoft GUID Struct Definition
typedef struct _GUID {
    unsigned long  Data1; // 4-byte 32-bit unsigned int (stored Little-Endian on x86)
    unsigned short Data2; // 2-byte 16-bit unsigned int (stored Little-Endian on x86)
    unsigned short Data3; // 2-byte 16-bit unsigned int (stored Little-Endian on x86)
    unsigned char  Data4[8]; // 8-byte array (stored Big-Endian / byte-by-byte)
} GUID;

Because Data1, Data2, and Data3 were defined as numeric integers rather than raw byte arrays, x86/x64 processors store them in little-endian order, while Data4 remains a raw byte array in big-endian order.

---

3. Byte-by-Byte Breakdown: Where the Mismatch Occurs

Let us trace what happens when we serialize the example UUID 00112233-4455-6677-8899-aabbccddeeff in Java/Python vs. C#.

The 16 Hexadecimal Bytes Compared:

Segment	Hex in UUID String	Java / Python (.bytes)	C# (.NET Guid.ToByteArray())	Status
Data1 (4 bytes)	00 11 22 33	00 11 22 33	33 22 11 00	🔄 Reversed (4 bytes)
Data2 (2 bytes)	44 55	44 55	55 44	🔄 Reversed (2 bytes)
Data3 (2 bytes)	66 77	66 77	77 66	🔄 Reversed (2 bytes)
Data4 (8 bytes)	88 99 aa bb cc dd ee ff	88 99 aa bb cc dd ee ff	88 99 aa bb cc dd ee ff	✅ Identical

What Happens During Base64 Encoding:

Java / Python Bytes:
00 11 22 | 33 44 55 | 66 77 88 | 99 aa bb | cc dd ee | ff
   ▼          ▼          ▼          ▼          ▼       ▼
 A B E i    M 0 R V    Z n e I    m a q 7    z N 3 u   / w = =
==> "ABEiM0RVZneImaq3zN3u/w=="

C# (.NET Default) Bytes:
33 22 11 | 00 55 44 | 77 66 88 | 99 aa bb | cc dd ee | ff
   ▼          ▼          ▼          ▼          ▼       ▼
 M y I R    A F V E    d 2 a I    m a q 7    z N 3 u   / w = =
==> "MyIRAFVEd2aImaq3zN3u/w=="

Notice that because the first 8 bytes are rearranged, the first 11 Base64 characters change entirely (ABEiM0RVZne vs MyIRAFVEd2a). The remaining characters (Imaq3zN3u/w==) align because the last 8 bytes are identical!

You can inspect the exact version and variant fields of your identifier with our free UUID / GUID Validator.

---

4. How to Fix the Problem in C# (.NET)

To achieve 100% interoperability with Java, Python, Node.js, and Go, C# must serialize the GUID into Big-Endian (RFC 9562 standard byte order) before Base64 encoding.

Modern C# (.NET 8 & .NET 9): The Native Way

Modern .NET versions include built-in parameters to control byte order directly:

using System;

Guid guid = Guid.Parse("00112233-4455-6677-8899-aabbccddeeff");

// ✅ RECOMMENDED: Pass bigEndian: true in .NET 8+
byte[] rfcBytes = guid.ToByteArray(bigEndian: true);
string base64 = Convert.ToBase64String(rfcBytes);

Console.WriteLine(base64);
// Output: ABEiM0RVZneImaq3zN3u/w== (Matches Java & Python!)

Legacy C# (.NET Framework / .NET Core / .NET 6 / .NET 7)

If you are running an older version of .NET where bigEndian: true is not available, you can manually flip the first three segments:

using System;

public static class GuidExtensions
{
    public static string ToRfcBase64(this Guid guid)
    {
        byte[] bytes = guid.ToByteArray();
        
        // Swap Data1 (4 bytes)
        Array.Reverse(bytes, 0, 4);
        // Swap Data2 (2 bytes)
        Array.Reverse(bytes, 4, 2);
        // Swap Data3 (2 bytes)
        Array.Reverse(bytes, 6, 2);

        return Convert.ToBase64String(bytes);
    }

    public static Guid FromRfcBase64(string base64)
    {
        byte[] bytes = Convert.FromBase64String(base64);
        
        // Swap back to Microsoft format before constructing Guid
        Array.Reverse(bytes, 0, 4);
        Array.Reverse(bytes, 4, 2);
        Array.Reverse(bytes, 6, 2);

        return new Guid(bytes);
    }
}

If you frequently work with Microsoft GUIDs and Windows tools, you can generate and format them with our GUID Generator.

---

5. How UUID to Base64 Works in Java

In Java, java.util.UUID stores the identifier as two 64-bit signed integers (mostSignificantBits and leastSignificantBits).

Standard Java Implementation (Big-Endian):

import java.nio.ByteBuffer;
import java.util.Base64;
import java.util.UUID;

public class UuidBase64 {
    public static String toBase64(UUID uuid) {
        ByteBuffer bb = ByteBuffer.allocate(16);
        bb.putLong(uuid.getMostSignificantBits());
        bb.putLong(uuid.getLeastSignificantBits());
        return Base64.getEncoder().encodeToString(bb.array());
    }

    public static UUID fromBase64(String base64Str) {
        byte[] bytes = Base64.getDecoder().decode(base64Str);
        ByteBuffer bb = ByteBuffer.wrap(bytes);
        long mostSig = bb.getLong();
        long leastSig = bb.getLong();
        return new UUID(mostSig, leastSig);
    }

    public static void main(String[] args) {
        UUID uuid = UUID.fromString("00112233-4455-6677-8899-aabbccddeeff");
        System.out.println(toBase64(uuid));
        // Output: ABEiM0RVZneImaq3zN3u/w==
    }
}

Because Java’s ByteBuffer operates in Big-Endian byte order by default, it writes bytes in standard RFC order.

---

6. How UUID to Base64 Works in Python

Python’s standard uuid module gives developers explicit control over endianness through two distinct properties:

• UUID.bytes: Produces Big-Endian (RFC standard order) — matches Java and standard systems.
• UUID.bytes_le: Produces Little-Endian (Microsoft mixed order) — matches default C# Guid.ToByteArray().

Standard Python Implementation (RFC Big-Endian):

import uuid
import base64

def uuid_to_base64(u: uuid.UUID) -> str:
    # Use .bytes for RFC standard (matches Java and .NET bigEndian: true)
    return base64.b64encode(u.bytes).decode('ascii')

def base64_to_uuid(b64_str: str) -> uuid.UUID:
    raw_bytes = base64.b64decode(b64_str)
    return uuid.UUID(bytes=raw_bytes)

# Test Example
my_uuid = uuid.UUID("00112233-4455-6677-8899-aabbccddeeff")
print(uuid_to_base64(my_uuid))
# Output: ABEiM0RVZneImaq3zN3u/w==

If You Need to Match Legacy C# in Python:

# Matching legacy .NET Guid.ToByteArray()
csharp_matching_b64 = base64.b64encode(my_uuid.bytes_le).decode('ascii')
print(csharp_matching_b64)
# Output: MyIRAFVEd2aImaq3zN3u/w==

---

7. Another Common Mistake: String Encoding vs. Byte Encoding

There is a second reason developers encounter UUID Base64 mismatches: encoding the 36-character string instead of the 16 binary bytes.

┌────────────────────────────────────────────────────────────────────────┐
│             RAW BYTES ENCODING VS STRING TEXT ENCODING                 │
├───────────────────────────────────┬────────────────────────────────────┤
│ CORRECT (16 Raw Bytes):           │ INCORRECT (36 ASCII String Bytes): │
│ Takes 16 raw bytes of UUID        │ Takes "00112233-4455..." text      │
│ Output length: 22–24 characters   │ Output length: 48 characters       │
│ Base64: ABEiM0RVZneImaq3zN3u/w==  │ Base64: MDAxMTIyMzMtNDQ1NS02Njc... │
└───────────────────────────────────┴────────────────────────────────────┘

Why String Encoding Is Inefficient:

• When you pass Encoding.UTF8.GetBytes(uuid.ToString()) or uuid_str.encode('utf-8') to Base64, you are encoding 36 bytes of ASCII text (including hyphens).
• This produces a bloated 48-character Base64 string (MDAxMTIyMzMtNDQ1NS...), defeating the entire purpose of binary compression!

---

8. Standard Base64 vs. Base64URL

When using Base64 UUIDs in REST API URLs, query parameters, or file paths, standard Base64 characters can cause routing bugs:

• Standard Base64 uses + (which web servers interpret as a space) and / (which web servers interpret as a directory separator).
• Standard Base64 ends with == padding characters.

The Solution: Base64URL (RFC 4648 §5)

Base64URL makes the string URL-safe and removes unnecessary padding:

1. Replace + with - (hyphen).
2. Replace / with _ (underscore).
3. Strip trailing = padding characters.

Standard Base64 (24 chars):  ABEiM0RVZneImaq3zN3u/w==
Base64URL (22 chars):        ABEiM0RVZneImaq3zN3u_w

Cross-Language Base64URL Quick Snippets:

• C#: Base64Url.Encode(guid.ToByteArray(bigEndian: true)) (in .NET 9)
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
• Python: base64.urlsafe_b64encode(u.bytes).decode('ascii').rstrip('=')

---

9. How to Debug UUID Base64 Mismatches

If your services are failing to look up records across APIs, follow this 3-step diagnostic checklist:

Step 1: Print the Hexadecimal Bytes in Both Systems
        Are both systems encoding [00, 11, 22, 33...] or is one encoding [33, 22, 11, 00...]?
        
Step 2: Check the Base64 Length
        • 22 chars = Unpadded Base64 / Base64URL
        • 24 chars = Standard Base64 with '==' padding
        • 48 chars = You accidentally encoded the 36-char text string!

Step 3: Check the Alphabet
        Does the string contain '+' and '/' (Standard) or '-' and '_' (Base64URL)?

If you need to analyze the version, variant, or timestamp structure of any identifier, use our free UUID Decoder & Analyzer.

---

10. Cross-Language Compatibility Matrix

Programming Language	Default Method	Byte Order	Matches Java?	Matches RFC 9562?	Recommended Universal Approach
Java	ByteBuffer.putLong()	Big-Endian	✅ Yes	✅ Yes	Native ByteBuffer
Python	uuid.bytes	Big-Endian	✅ Yes	✅ Yes	uuid.bytes
Python (Legacy)	uuid.bytes_le	Mixed-Endian	❌ No	❌ No	Only for legacy .NET interop
C# (.NET 8+)	guid.ToByteArray(true)	Big-Endian	✅ Yes	✅ Yes	guid.ToByteArray(bigEndian: true)
C# (Default)	guid.ToByteArray()	Mixed-Endian	❌ No	❌ No	Avoid for cross-language APIs
JavaScript / TS	crypto.randomUUID()	Big-Endian	✅ Yes	✅ Yes	Standard 16-byte Buffer
Go	uuid.MarshalBinary()	Big-Endian	✅ Yes	✅ Yes	Native byte slice

---

11. Frequently Asked Questions (FAQ)

Why does C# produce a different Base64 UUID than Java and Python?

C# (.NET) historically serializes GUIDs using Microsoft mixed-endian format (Guid.ToByteArray()), which reverses the byte order of the first three components. Java and Python serialize UUIDs in standard RFC Big-Endian order.

How do I make C# Base64 match Java and Python?

In .NET 8 and .NET 9, call guid.ToByteArray(bigEndian: true). In earlier .NET versions, reverse bytes 0–3, 4–5, and 6–7 before Base64 encoding.

Should I Base64 encode the UUID string or the raw 16 bytes?

Always encode the raw 16 binary bytes. Encoding the 16 bytes produces a compact 22-character string. Encoding the 36-character text string produces an inefficient 48-character string.

What is the difference between UUID.bytes and UUID.bytes_le in Python?

UUID.bytes returns the 16 bytes in standard RFC Big-Endian order (matching Java and standard network protocols). UUID.bytes_le returns the 16 bytes in Microsoft Little-Endian / Mixed-Endian order (matching legacy C#).

Is Base64 UUID conversion reversible?

Yes. 16 raw bytes can be decoded from Base64 back into the exact original 128-bit UUID without any loss of data or precision.

How long is a Base64-encoded UUID?

A 16-byte UUID encoded in standard Base64 is 24 characters (including two = padding characters). When encoded in unpadded Base64URL, it is 22 characters.

---

12. Conclusion & Developer Tools

The mystery of different Base64 UUIDs across C#, Java, and Python is not caused by broken Base64 algorithms—it is purely an endianness and byte-order issue.

By adopting RFC Big-Endian (Network Byte Order) as your universal serialization standard across all services, your microservices and APIs will achieve seamless, bug-free identifier interoperability.

Explore our full suite of free developer tools on FastUUIDGenerator.com:

• Base64 UUID Generator — Convert 128-bit UUIDs into compact 22-character Base64 and Base64URL strings.
• UUID Generator — Create instant, cryptographically secure UUID v4 and v7 identifiers.
• GUID Generator — Generate Microsoft & .NET ready GUIDs.
• UUID / GUID Validator — Validate syntax, inspect version & extract timestamps.
• UUID Decoder — Decode timestamps and metadata from UUID v1, v6, and v7.
• Bulk UUID Generator — Generate up to 10,000 identifiers in batch.