Custom PRD build: A Zero-Upload JWT Inspector
Reviewed by the OnlineFree.app team · Updated
Key points
- Custom PRD build decodes JWT headers and payloads entirely in the browser, so tokens and secrets are never uploaded.
- The expiry badge reports valid, expired, missing exp or not-yet-valid with a humanized time delta such as 'expires in 3h 12m'.
- HMAC signatures for HS256, HS384 and HS512 can be verified locally; RS, ES and PS tokens cannot.
- A token must contain exactly two dots and three non-empty base64url segments before it will decode.
- The tool decodes and checks expiry only — it does not validate audience or issuer against your configuration.
What is Custom PRD build?
It is a browser-only JSON Web Token inspector: paste a compact JWS string and it renders the decoded header and payload instantly, flags whether the token is still valid, and never sends the token anywhere. That last part is the whole point — debugging auth usually means handling a credential that is still live.
The tool sits at Custom PRD build and takes three inputs: the token itself, an optional shared secret, and an optional expected algorithm. It returns pretty-printed header and payload JSON, a flat claims table with iat/exp/nbf converted to human dates, an expiry badge, and — for HMAC tokens only — a signature verdict.
It is aimed at one short moment: you have copied a token out of a log line or the DevTools Application tab, your request is 401ing, and you need to know in the next thirty seconds whether the token is expired, malformed, or signed with the wrong algorithm.
How to inspect a token in under a minute
Paste the token into the left-hand textarea. The validator expects exactly two dots and three non-empty base64url segments; if you copied `Bearer eyJ...`, the scheme prefix is stripped for you, and stray spaces or newlines raise a warning rather than failing silently.
The right pane splits into pretty-printed header and payload JSON alongside a claims table that renders iat, exp and nbf as readable dates. The expiry badge sits with them: `Valid (expires in 3h 12m)` for a live token, `Expired 2d ago` for one that lapsed, `No exp claim` for tokens that never expire, and `Not yet valid` when nbf is still in the future.
If the token is HS256, HS384 or HS512 and you hold the shared secret, open the collapsible secret field and paste it. The HMAC is recomputed locally and the tool reports `signature verified` or `signature mismatch`. The secret stays in the page — it is never transmitted, not even to FreeOnline.fyi's own servers.
If you know what your service should accept, set the expected-algorithm select to HS256, HS384, HS512 or RS256. A disagreement with `header.alg` raises an alg-mismatch banner, which is the quickest way to catch an algorithm-confusion bug before it reaches production. The same paste-and-read pattern shows up across the other free online tools on the site.
What do exp, nbf and iat actually mean?
exp, nbf and iat are NumericDate values: seconds since the Unix epoch, not milliseconds. That single detail causes a lot of confusion, because `1700000000` reads like a millisecond timestamp but is actually 14 November 2023 — a token with that exp expired years ago.
A payload with no exp never triggers an expiry failure in most libraries, so `No exp claim` is a legitimate finding, not a tool error. Tokens with exp far in the future are just as suspicious as expired ones; an access token meant to live 15 minutes but carrying a two-day exp usually means a refresh token was pasted by mistake.
The not-before claim deserves the same scrutiny. If nbf is a few minutes ahead of your server's clock, the token fails with a confusing error even though exp is fine — that is `Not yet valid` in the badge. Many stacks allow a small clock-skew leeway of a few seconds to a minute, so a token that is one second past exp may still be accepted by some services and rejected by others. Reissue rather than argue with the boundary.
Why zero-upload matters for production tokens
A JWT is a bearer credential: anyone holding the string can use it until exp passes. That makes where you paste it a security decision, not a convenience one. Some online decoders process tokens server-side, which means a live access token could land in a request log or a third party's storage.
Custom PRD build decodes in JavaScript on your own machine, so the token and any secret you type stay in the tab. You do not have to take that on faith — open your browser's Network panel, paste a test token, and watch for requests while you interact with the page. If nothing carries the token, the decode is local. That verification habit is worth applying to any decoder you use.
Even so, hygiene beats trust. Debug with tokens issued for a scratch account where you can, prefer short-lived access tokens, and revoke anything you pasted somewhere you later regretted. The tool being offline-capable is a strong control, not a licence to paste production credentials into every tab you have open.
How Custom PRD build compares to other JWT debuggers
Compared with a local script — `JSON.parse(Buffer.from(token.split('.')[1], 'base64url'))` in Node, or `jwt.decode` in Python — Custom PRD build skips the runtime, the cwd and the dependency install. Compared with a full library such as jose or jsonwebtoken, it does far less: no key resolution, no JWKS fetch, no audience or issuer validation against your config. It shows you `aud` and `iss` in the claims table and leaves the judgement to you.
That narrower scope is deliberate. As of 2026 the signature check covers HMAC only, so RS256, ES256 and PS256 tokens return `cannot verify (RS/ES/PS)`. Asymmetric verification needs a public key at minimum and usually a JWKS endpoint, which is a library job. The tool also does not sign or mint tokens, and does not check your server's clock skew settings.
Read the spectrum honestly. For a thirty-second look at one token, paste beats a REPL. For a CI pipeline, a key rotation, or a security review, use a maintained library — it will validate the claims that actually matter, and the same applies when you are reviewing a written spec rather than a token, which is what the companion Custom PRD build workflow is for. Standards-wise, the token structure is defined in RFC 7519 and the signing mechanics in RFC 7515 — both worth reading once.
Frequently asked questions
Is Custom PRD build safe to use with production JWTs?
Yes, within reason. Custom PRD build decodes tokens entirely in the browser, so the string you paste is never uploaded, logged or stored. The HS256/384/512 signature check runs locally too. Even so, a JWT is a bearer credential: use a scratch account where possible, prefer short-lived tokens, and revoke anything you exposed in a channel you later doubt.
Can Custom PRD build verify an RS256 or ES256 signature?
No. As of 2026, Custom PRD build verifies HMAC signatures only — HS256, HS384 and HS512 — because those need nothing beyond the shared secret. Tokens signed with RS256, ES256 or PS256 return a 'cannot verify (RS/ES/PS)' verdict: you still get the decoded header and payload, but confirming the signature needs your public key, typically through a library or a JWKS fetch.
Why does my token fail the 'exactly two dots' check?
The tool requires a compact JWS string with exactly two dots and three non-empty base64url segments. A JWE has four dots, a token copied from a UI may include curl quotes or a trailing newline, and truncation from a log viewer is common. Strip whitespace and the 'Bearer ' prefix, then confirm you copied header, payload and signature intact.
What does the alg mismatch warning mean in Custom PRD build?
It means the algorithm you selected in the expected-algorithm field does not match header.alg in the pasted token. If your service should only accept HS256 but the token says RS256, that is an algorithm-confusion risk worth investigating rather than a tool bug. Leave the field on 'auto' when you only want to see what the token claims.
Does Custom PRD build work on a phone?
Yes. The layout stacks vertically on mobile: token input on top, a sticky expiry badge directly beneath it, then Header, Payload and Claims tabs instead of side-by-side panes. Copy buttons go full width with 44px tap targets, and the optional secret field stays tucked away. Decoding and HS verification behave identically to the desktop view.