{{ valid ? 'Valid' : 'Invalid' }} {{ addressType }}
Compressed:
Expanded:
  • {{ row.label }} {{ row.value }}
Group Hex Decimal
{{ i + 1 }} {{ g }} {{ parseInt(g,16) }}

Introduction:

Internet Protocol version 6 (IPv6) replaces the limited 32-bit address space of IPv4 with 128 bits, preventing exhaustion while supporting hierarchical routing, multicast, and autoconfiguration. Each address is written as eight 16-bit hexadecimal groups separated by colons, balancing human readability with immense numerical scale that complicates everyday inspection and error avoidance.

This client-side tool accepts a single IPv6 string, verifies structural correctness under RFC 5952 guidelines, expands suppressed zeros, recompresses the longest contiguous zero block, detects standard prefix categories, separates network and interface identifiers, and renders a 128-bit binary view, all through an in-browser reactive engine that never stores or transmits data.

During outage triage you can paste an address captured from packet traces, instantly verify validity, copy the uniformly compressed value into automation playbooks, or document loopback and link-local scopes in tickets. Typos spread rapidly through configuration management systems; always validate every quartet before committing device or firewall changes to shared repositories.

Technical Details:

IPv6 encodes host and network information in 128-bit unsigned integers expressed as hexadecimal quartets. Leading zeros within each quartet may be omitted, and a single contiguous run of zero quartets may be compressed to a double colon. These conventions drastically shorten everyday addresses but make textual variants non-unique, so reliable tooling must consistently expand, validate, recompress, and classify values to compare prefixes, generate reverse-DNS records, or derive interface identifiers reliably.

Core Process

  1. Trim whitespace, convert to lowercase, and reject multiple :: tokens.
  2. Split on ::; pad the missing quartets with zero strings until eight groups exist.
  3. Left-pad individual quartets with zeros to four digits, producing the fully expanded canonical form.
  4. Identify the longest consecutive zero sequence, replace it with ::, and remove redundant leading zeros to create the compressed form.
  5. Evaluate the first quartet to label the address as loopback, link-local, unique-local, multicast, documentation, or global.
  6. Translate each quartet from hexadecimal to binary, concatenating all 128 bits for bit-level inspection.

Address-Type Prefixes

TypeLeading PatternTypical Scope
Loopback::1Local host only
Unspecified::Unknown source
Link-localfe80::/10Single segment
Unique-localfc00::/7Private network
Multicastff00::/8Group addressing
Documentation2001:db8::/32Examples only
GlobalAll othersPublic Internet

The first quartet quickly signals routing behavior. For instance, multicast addresses beginning with ff never identify single hosts, whereas link-local addresses cannot traverse routers.

Key Variable

  • ipv6 – raw user-supplied IPv6 string; accepts upper- or lowercase hexadecimal, optional shorthand.

Example (input 2001:db8::ff00:42:8329):

Expand → 2001:0db8:0000:0000:0000:ff00:0042:8329 Compress → 2001:db8::ff00:42:8329 Type → Documentation address

Assumptions & Limitations

  • Input must be a single IPv6 address, not a CIDR range.
  • Parsing follows RFC 5952 textual representation rules.
  • Tool ignores zone identifiers (for example, %eth0).
  • Address-type classification relies solely on leading bits, not on registries.

Edge Cases & Error Sources

  • Multiple :: tokens invalidate the address.
  • More than eight quartets trigger rejection.
  • Non-hexadecimal characters cause failure.
  • Leading or trailing colons outside compression syntax are treated as errors.

Scientific Validity & References

The procedure conforms to RFC 4291 (IPv6 Addressing Architecture) and RFC 5952 (Preferred IPv6 Text Representation) and aligns with examples in IETF BCP 198.

Privacy & Compliance

Address strings are processed wholly within the browser; no personal data is transmitted, ensuring GDPR compliance.

Step-by-Step Guide:

Follow these steps to validate and normalize an IPv6 address.

  1. Paste or type the address into the IPv6 address field.
  2. Observe the immediate Valid/Invalid badge in the summary.
  3. If valid, review the compressed and expanded forms and copy whichever version you need.
  4. Select the Info, Groups, or Binary tab to inspect additional details.
  5. Use the Copy buttons to transfer results into documentation or configuration files.

FAQ:

What counts as valid?

An address is valid when it contains exactly eight hexadecimal quartets after expansion, uses at most one double-colon for compression, and includes only characters 0-9 and a-f.

Is my data stored?

No. All processing runs locally in your browser and nothing leaves your device.

Why is ::1 called loopback?

The ::1 address routes traffic back to the originating host’s network stack, letting you test services without external connectivity.

What does “compressed” mean?

The compressed form removes leading zeros and shortens the longest all-zero sequence to ::, yielding the shortest canonical representation per RFC 5952.

Can I input CIDR ranges?

No. Supply individual host addresses only; network prefixes such as 2001:db8::/32 will be rejected by the validator.

Glossary:

Quartet
Four hexadecimal digits representing 16 bits.
Compression
Technique of shortening the longest zero run to ::.
Network ID
Top 64 bits identifying the network segment.
Interface ID
Lower 64 bits uniquely identifying a host on the segment.
RFC 5952
IETF document describing preferred IPv6 text representation.
Embed this tool into your website using the following code: