Home / UUID Tools / UUID to Integer Converter

UUID Tools

UUID to Integer Converter

Convert a UUID to its exact unsigned 128-bit integer and back, then inspect the same 16 bytes as hex, binary, Base64URL, Java 64-bit halves, and .NET GUID byte layouts.

uint128 · exact round-trip · bytes · Java · .NET · batch audit

UUID ↔ Integer Representation Studio

Inspect one 128-bit value across UUID text, unsigned decimal, hex, binary, Base64URL, byte arrays and platform-specific handoff forms without changing the underlying bits.

128-bit representation studio

UUID ↔ uint128Hex · binary · Base64URLRFC byte evidenceJava + .NET handoffBatch CSV / JSON

Interpret input asUUID

Ready.

Exact representation audit

—canonical UUID

—decimal digits

—version field

—variant

The decimal value is the 16 RFC/display-order bytes interpreted as one unsigned big-endian integer. Leading zero bits disappear in decimal text but are restored on integer → UUID round-trip.

Platform handoff evidence

Java `UUID` 64-bit halves

.NET `Guid.ToByteArray()` legacy layout

Timestamp evidence

—

Portable project & repeat-use handoff

Project JSON contains the current identifier and derived representations. Local saves happen only when you click Save locally and keep at most 12 projects. Reproducible links include the entered UUID/integer in the URL query string, so do not use them for identifiers you consider sensitive.

#	UUID	Saved
No explicitly saved projects.

Current audit summary

Batch UUID / integer audit

One UUID or unsigned decimal integer per line, up to 500 non-empty rows. Each valid row is normalized to canonical UUID and exact uint128 decimal before export.

Batch not run yet.

Line	Input	Canonical UUID	uint128	Version

Truth boundaries

A UUID is 128 bits. Decimal, hexadecimal, binary and Base64 forms are representations of those same bits when the byte order is held constant; conversion does not create a new identifier or change collision properties.
The primary uint128 value uses RFC/display byte order, matching a left-to-right parse of the 32 UUID hex digits. Microsoft Guid.ToByteArray() historically exposes a different byte layout for the first 4+2+2-byte fields; that legacy byte array is shown separately, never silently substituted.
Java exposes the most- and least-significant 64-bit halves as signed long values. Negative decimal display does not mean the UUID bits are negative; the unsigned 64-bit values are shown beside them.
Only standardized time-bearing UUID versions/variants receive timestamp evidence. A decimal integer is not a creation time and numeric ordering is not automatically chronological for arbitrary UUIDs.
Large UUID integers exceed JavaScript Number and many spreadsheet/JSON numeric precision limits. Treat the decimal value as text or use a native 128-bit/BigInt-capable type downstream.
UUIDs are identifiers, not authentication secrets. This tool runs the conversion in your browser, but copied values, downloaded projects and reproducible URLs can still expose whatever identifier you put into them.

One UUID, many exact representations

The canonical UUID string is a readable rendering of 16 bytes. Removing hyphens and reading those 32 hexadecimal digits as one unsigned big-endian number produces the uint128 decimal representation used by this page. Converting that integer back to exactly 32 hex digits restores leading zero bits and therefore the original UUID text.

Worked round-trip check

00000000-0000-0000-0000-000000000001 converts to decimal 1. The integer text no longer displays the 127 leading zero bits, but the reverse conversion pads the value back to 128 bits and recreates the UUID exactly.

Verification rule: compare the 16 RFC-order bytes, not just the typography. UUID, compact hex, uint128, Base64 and byte arrays should all decode to the same 16 bytes.

Why Java and .NET need separate evidence

Java's UUID API exposes the same 128-bit value as a most-significant and least-significant 64-bit long. Because Java long is signed, either half can print as a negative decimal even though the bit pattern is unchanged. .NET GUID byte arrays add a different interoperability trap: the traditional byte-array layout reverses the first three UUID fields relative to the usual display byte order. This studio labels those platform forms explicitly rather than calling all byte arrays equivalent.

Do not infer timestamp meaning from the decimal size

UUID versions define how some bits are interpreted. Only standardized time-bearing forms should be decoded as timestamps, and conversion to a large integer does not make random, name-based or custom UUIDs chronological.

Practical guide and verification

Use the tool first, then apply these checks to verify the inputs, interpret the result, and hand it off without displacing the primary workflow.

Interpret the conversion as representation, not identity change

A UUID and its unsigned 128-bit integer representation contain the same 16 bytes when the byte order is held constant. Converting the display format does not create a new identifier, change UUID version semantics, or make an identifier more or less unique.

Preserve leading zero bits on round trips

Decimal integers do not show leading zeroes, while a UUID always represents 128 bits. A reverse conversion must restore the full 32 hexadecimal digits before adding hyphens. Use the dedicated integer-to-UUID workflow when checking exact round-trip behavior.

Do not infer time from arbitrary UUID versions

Only UUID versions with standardized time fields support meaningful timestamp extraction. A large decimal value does not imply chronological order, and converting random or name-based UUIDs to integers does not turn them into sortable creation times.

Keep numeric-system limits in downstream software

JavaScript BigInt can represent the full unsigned 128-bit value, but databases, spreadsheets, JSON consumers, and programming languages may not. Export or copy the decimal value as text when the next system cannot represent 128-bit integers exactly.