What the JWT Visualizer Does
The JWT Visualizer takes a token apart and lays its three segments out as plain text — with exact character counts for each. Paste a JWT and run the transform, and the output panel shows a structured report: HEADER (36 chars) followed by the decoded header JSON, PAYLOAD (74 chars) followed by the decoded payload JSON, and the SIGNATURE segment printed as-is beneath them.
The character counts are the part no plain decoder gives you. Segment lengths in a compact JWT are pure information: the header is nearly always 36 characters for HS256, the payload grows with every claim you add, and the signature is fixed at 43 characters for HS256 (32 bytes, Base64Url-encoded, no padding). Seeing those three numbers side by side tells you at a glance whether a token is carrying a heavy claims set, whether it was signed at all, and whether something in a transport layer truncated it.
The tool is a reader, not a verifier — the signature is displayed but never checked, and no key is ever requested. It answers "what is this token made of and how big is each part", which is the question you are actually asking when a token looks wrong in a log, a cookie banner, or a header-too-large error.
How the JWT Visualizer Works
The processing is a two-step decode per segment. The token is split on dots into up to three parts. The first two — header and payload — are Base64Url-decoded: the URL-safe characters (-, _) are mapped back to standard Base64's (+, /), padding is restored, and the resulting bytes are read as UTF-8 text. For a well-formed token those bytes are JSON, displayed verbatim.
The signature gets different treatment, deliberately. It is not JSON and not decodable to text — it is 32 raw bytes of HMAC-SHA256 output for HS256 — so printing it as text would produce mojibake. The tool shows the Base64Url characters themselves, exactly as they appear in the token. That is also why the report labels it SIGNATURE without a decoded section: there is nothing to decode, only bytes to compare.
The length annotations are computed on the raw encoded segments, before any decoding. That choice matters: encoded length is what consumes header space, cookie capacity, and log volume, and it is what transport layers truncate. A payload segment that grows past a proxy's header limit does so in encoded characters, not decoded bytes — the annotation counts the thing that breaks.
Missing segments degrade gracefully. A two-segment token (the alg:none shape) reports (none) for the signature section. A token shorter than two segments is rejected with an explicit error rather than a partial report, since there is nothing meaningful to visualise.
Using the JWT Visualizer
- Step 1 — Paste the complete token. From a request header, a cookie's value, a log line, or your browser's network tab. Whitespace around the token is fine.
- Step 2 — Run the transform. No options, no keys. The tool needs nothing but the token itself.
- Step 3 — Read the annotated sections. Each section opens with its segment's character count, then the decoded content. Compare the payload count against the header count to gauge claims weight; confirm the signature is present before assuming a token is signed.
- Step 4 — Use the counts for transport debugging. If an endpoint rejects large authorisation headers, the payload count tells you how much of the budget your claims consume. Trimming one bulky claim shrinks the token by a predictable amount.
- Step 5 — Escalate for meaning. For claim-level inspection use the JWT Decoder; for expiry math the JWT Expiry Checker; for authenticity the JWT HS256 Verifier. This tool's lens is structure and size.
Common Use Cases
Diagnosing header-size failures. Tokens ride in Authorization headers, and proxies and servers enforce limits. When a request fails with a header-too-large error, visualising the token shows exactly which segment is heavy and how much needs to come out.
Spotting truncation in logs. A log viewer that clipped a token leaves a short final segment. The signature count makes it obvious: HS256 signatures are 43 characters, so anything shorter was cut somewhere between the wire and the log.
Teaching token anatomy. The annotated three-section layout — sizes and contents together — makes the header/payload/signature structure legible in seconds, which is why it works well in onboarding docs and interview walkthroughs.
Comparing tokens quickly. Two tokens from the same issuer should have near-identical header sizes and payload shapes. A visualiser run on each shows divergences — a different algorithm in the header, an unexpected claim in the payload — before you read a single JSON value closely.
Confirming a token is signed at all. A missing or empty signature section is instantly visible. That sounds trivial until an alg:none token or a hand-built two-segment string reaches your queue and the question "is this even signed?" needs a fast answer.
Worked Example
Paste the canonical demonstration token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.1VAmegkQOBsQ-iSZU96z6c8NY7QR9OhhYWYHwHTeGT4
The output panel shows:
HEADER (36 chars)
{"alg":"HS256","typ":"JWT"}
PAYLOAD (74 chars)
{"sub":"1234567890","name":"Jane Doe","iat":1516239022}
SIGNATURE
1VAmegkQOBsQ-iSZU96z6c8NY7QR9OhhYWYHwHTeGT4
Read the numbers first. Header: 36 characters — the standard HS256 header, as expected. Payload: 74 characters for three modest claims, which shows how quickly encoded JSON grows (roughly two-thirds of it is Base64 overhead and key names). Signature: the full 43-character HS256 signature, displayed but not decoded — there is nothing to decode.
Now the structural comparison this tool exists for: add a bulkier claim — "roles":["admin","editor","auditor"] — to the same token and the payload segment grows by roughly 40 characters while header and signature stay put. The size story of a JWT is always the payload's, and this report is where you watch it.
Tips and Common Mistakes
- The counts are encoded lengths. They measure the Base64Url characters that travel over the wire — the right unit for header budgets and truncation debugging, but larger than the decoded JSON's own length. Do not mix the two when estimating limits.
- HS256 signature length is a constant. 43 characters, always. A different length means the token was not HS256-signed (RS256 signatures are 342 characters for a 2048-bit key) or was truncated in transit.
- Display is not verification. The signature is shown for completeness and comparison; its validity is never checked here. A tampered payload visualises exactly as cleanly as a signed one.
- Decoded JSON is shown verbatim, not reformatted. The tool prints the decoded bytes as-is, so key order and spacing are whatever the issuer produced. Byte-level comparisons between tokens are meaningful; whitespace differences are not claims differences.
- Encrypted JWTs (JWE) will fail. Five dot-separated segments is the encrypted form; the payload is ciphertext and there is nothing to visualise. This tool is for the three-segment signed form.
- Large pastes are fine; secrets are still secrets. The tool runs locally and transmits nothing, but the same caution applies here as everywhere: prefer expired or test tokens when you can, and treat live production tokens as sensitive regardless of where you paste them.
Frequently Asked Questions
What is the difference between this and the JWT Decoder?
Both decode the same two segments. The decoder outputs machine-shaped JSON with algorithm and expiry info — built for reading claims. The visualiser outputs an annotated plain-text layout with segment character counts — built for seeing structure and size. Use the decoder when you want to know what the token says; use this when you want to know what the token is.Why isn't the signature decoded?
Because it is not text. For HS256 the signature is 32 raw bytes of HMAC-SHA256 output; rendering those bytes as UTF-8 yields gibberish. The Base64Url characters in the token are the only human-readable representation the signature has, so the tool shows them as-is. Decoding a signature is a category error, not a missing feature.What should the signature length be?
For HS256, exactly 43 characters — 32 bytes Base64Url-encoded with padding stripped. For RS256 with a 2048-bit key, 342 characters (256 bytes). A different length is a strong hint of truncation, an unexpected algorithm, or a token that is not what its header claims. The count is printed precisely so this check takes one glance.Can it show me why my token was rejected?
Only structurally. Size-related rejections (header limits), truncation, and missing signatures all show up clearly. Claim rejections, expiry, and signature failures need the decoder, expiry checker, or verifier respectively. Think of this tool as the X-ray: it shows bones, not health.Does it support color-coded segment diagrams?
No — the output is a plain-text report, by design: it copies cleanly into tickets, docs, and terminals. If you want the annotated breakdown of what each segment means rather than its layout, the
JWT Decoder and the JWT Validator between them cover the same ground in report form.
Related Tools