Custom PRD build: Decode a JWT in the Browser, Step by Step
Reviewed by the OnlineFree.app team · Updated
Key points
- Custom PRD build decodes JWT headers and payloads entirely in the browser with no upload.
- JWT exp, iat, and nbf values are seconds since the Unix epoch, not milliseconds.
- The expiry badge has four states: Valid, Expired, No exp claim, and Not yet valid.
- Signature verification works for HS256, HS384, and HS512 only; RS, ES, and PS cannot be verified.
- A valid expiry badge never proves a token is authentic or unrevoked — verify server-side.
What does Custom PRD build do with a pasted token?
Custom PRD build decodes a JSON Web Token's header and payload entirely inside your browser and tells you whether the token has expired. The compact JWS string you paste is never uploaded, so you are not handing a live credential to a third-party server.
A JWT is three base64url segments joined by two dots: header.payload.signature. The header usually names the signing algorithm and token type, the payload carries the claims (subject, scopes, iat, exp), and the signature binds the first two parts to a key. Base64url is an encoding, not encryption, which is why anyone holding the string can read it.
The tool is built for the 30-second case: you copied a token out of a log line or DevTools and need to know what is inside it and when it dies. Paste it into Custom PRD build and you get header JSON, payload JSON, a flat claims table, and an expiry badge on one screen.
Paste a JWT and read the answer in five steps
Step one: copy the whole compact token, from the first `eyJ` to the final character. In Chrome or Firefox DevTools, check Application → Cookies for a token cookie, or the Authorization request header in the Network tab. Partial copies are the most common reason a paste fails.
Step two: paste it into the textarea on the left. The input validation expects exactly two dots splitting three non-empty base64url segments; a leading `Bearer ` prefix is stripped automatically, and the tool warns you if it detects whitespace or line breaks introduced by log wrapping. Step three: read the two JSON panes on the right — header on top, payload below — plus the claims table that flattens nested values into rows.
Step four: check the expiry badge, which shows a humanized delta such as "Valid (expires in 3h 12m)" or "Expired 2d ago". Step five: use the copy buttons to grab a claim or a payload field. On desktop the layout is split left-to-right so the verdict never scrolls off-screen; on mobile the input sits on top, the badge sticks directly beneath it, and Header, Payload, and Claims become tabs with full-width 44px tap targets.
How do you read the iat, exp and nbf claims?
The `exp`, `iat`, and `nbf` claims are NumericDate values: seconds since the Unix epoch, not milliseconds. That single detail causes a lot of confusion. A JavaScript bug that writes `Date.now()` into `exp` produces a value roughly 1,000 times too large, so a token that claims to expire in the year 57,000 is really a millisecond timestamp in disguise.
As a sanity check, epoch seconds in 2026 sit in the range of roughly 1.77 to 1.80 billion. Anything with 13 digits (trillions) is milliseconds; anything with 10 digits is seconds. `iat` tells you when the token was minted, which is useful for spotting a cached token that predates your latest deploy, and `nbf` means the token must not be accepted before that instant.
Custom PRD build renders all three as human-readable dates and shows the delta to your current time, so you do not have to do the arithmetic. Servers often apply a small clock-skew leeway — commonly anywhere from zero to 60 seconds — so a token with 30 seconds left may still work on one service and be rejected by another. Treat the badge as a strong hint and confirm against the API before you conclude the auth flow is broken.
What the expiry badge does and does not tell you
The badge has four states: Valid, Expired, No exp claim, and Not yet valid. "Valid" includes a countdown such as "expires in 3h 12m". "Expired" shows how long ago, for example "Expired 2d ago". "No exp claim" means the token never self-expires, which is worth flagging in review — long-lived tokens widen the damage window if one leaks. "Not yet valid" means `nbf` is still in the future, usually a sign of a clock mismatch between the issuer and your machine.
The verdict is computed against your device's clock. If your laptop is five minutes behind the issuer, a perfectly good token can look expired. If the answer surprises you, compare `exp` against a second source before filing a bug.
More importantly, the badge says nothing about revocation. JWTs are stateless: a server that has blacklisted a token, rotated a signing key, or logged the user out will still reject a token that the badge calls Valid. Keep `exp` short and treat the badge as a decoding aid, not an authorization decision.
Verifying an HS256 signature with the optional secret
The collapsible secret field is optional and only meaningful for HS256, HS384, and HS512. Paste the shared secret and the tool recomputes the HMAC over `header.payload` and compares it to the third segment, reporting "signature verified" or "signature mismatch". The secret is used locally and is never sent anywhere.
The expected-algorithm dropdown defaults to auto. If you set it to HS256 and the token's header says RS256, you get an "alg mismatch" banner. That warning matters: algorithm-confusion attacks rely on a verifier accepting whatever `alg` the token declares, so pinning the expected algorithm on the server side is a standard defense documented in the OWASP JSON Web Token Cheat Sheet.
Symmetric verification only goes so far. RS256, ES256, and PS256 tokens need the issuer's public key, which this tool does not accept, so it reports "cannot verify (RS/ES/PS)". Asymmetric tokens are still fully decoded — header, payload, claims, and expiry all work — you simply cannot confirm the signature here. The claim structure itself is defined in RFC 7519.
Limits, edge cases and privacy notes
The parser requires exactly two dots. A JWE (encrypted token) has five segments and will not decode, because its payload is ciphertext rather than readable claims. Truncated tokens copied from a terminal, tokens with a trailing newline, and payloads that are not valid JSON all produce an error rather than a misleading result.
Decoding is not proof of authenticity. Anyone can craft a payload with `sub: admin` and no valid signature, and the inspector will happily display it. Always pair the decode with a real signature check on the server, and treat `alg: none` tokens as unsecured by definition.
On privacy: nothing is uploaded, which removes the "pasting production credentials into someone's server" problem, but a JWT is still a bearer credential. Avoid screenshotting tokens into chat, redact the signature segment when you share a payload, and remember that payloads frequently contain emails, tenant IDs, and scopes. If you want to inspect other browser-side data next, browse the rest of FreeOnline.fyi — and if you need the alternate build of this inspector, it lives at Custom PRD build.
Frequently asked questions
Is it safe to paste a production JWT into Custom PRD build?
Yes, in the sense that the token is decoded locally in your browser and never uploaded to a server. Custom PRD build has no network call for decoding, so a live credential does not leave your machine. It is still a bearer token, though — avoid screenshotting it, redact the signature segment before sharing an example, and prefer testing with a staging token when you can.
Can Custom PRD build verify an RS256 token's signature?
No. Signature verification in Custom PRD build covers HS256, HS384, and HS512 only, because those use a shared secret you can paste. RS256, ES256, and PS256 require the issuer's public key, so the tool reports "cannot verify (RS/ES/PS)" — but the header, payload, claims table, and expiry badge still work normally for those tokens.
Why does Custom PRD build say my token expired when my API still accepts it?
Two likely reasons. First, your device clock may differ from the issuing server's clock, and the expiry badge is calculated against local time. Second, many APIs allow a small clock-skew leeway — often up to 60 seconds — before rejecting an expired token. Check the exact `exp` value against server time before treating this as a bug.
Does a decoded JWT payload prove the token is authentic?
No. A JWT payload is base64url-encoded, not encrypted or signed at the point of display, so anyone can read it and anyone can forge plausible-looking claims. The signature segment is what proves authenticity, and it must be checked with the correct key. Treat decoded claims as untrusted input unless the signature has been verified server-side.
What token formats does Custom PRD build reject?
Custom PRD build accepts a compact JWS string with exactly two dots and three non-empty base64url segments. It rejects JWE tokens with five segments, since those payloads are ciphertext, plus truncated tokens and payloads that are not valid JSON. A leading "Bearer " prefix is stripped automatically, and whitespace or wrapped lines trigger a warning.