Skip to content
Lizely

JWT Decoder

Decode a compact JWT header and payload locally, with a clear unverified warning.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste a compact JWT in header.payload.signature form.
  2. 2.Select Decode JWT to inspect the locally decoded header and payload.
  3. 3.Treat the result as unverified information and validate the token in its owning application when trust matters.

About JWT Decoder

JWT Decoder is a deliberately narrow browser tool for reading the header and payload of a compact JSON Web Token. Paste a token in the familiar header.payload.signature form and the page decodes the first two Base64url segments as UTF-8 JSON objects. It then shows the header, payload, and any registered claims it recognizes, including issuer, subject, audience, expiration time, not-before time, issued-at time, and JWT ID. The decoder runs locally in your browser. It does not upload the token, send it to an API, fetch a signing key, store a copy, or create an account. That makes it useful for a quick development inspection when you already have authority to view the token.

Decoding is not verification. A readable payload can be forged, expired, meant for a different audience, or signed with a key you do not trust. This page does not accept a secret or public key, validate a JWS signature, check an issuer, check an audience, apply clock skew, decrypt a JWE, or make an authorization decision. The result should never be used as proof that a login is valid or that a person may access a system. Use the authentication library and key-management flow of the application that issued the token whenever trust matters. This page labels every successful decode as unverified so that a convenient inspection step is not mistaken for a security check.

The expected input is the three-segment compact JWS representation described by RFC 7519. The header and payload segments must use the URL-safe Base64 alphabet from RFC 4648: letters, digits, hyphen, and underscore. JWT compact serialization normally omits Base64 padding, so this tool rejects padding characters and structurally impossible segment lengths instead of silently accepting a different format. It also requires the decoded header and payload to be JSON objects. Arrays, null, plain text, malformed JSON, a missing segment, an extra segment, invalid Base64url characters, and invalid UTF-8 are reported as errors. The third segment is checked only for compact Base64url shape; its bytes are never interpreted as a successful signature. An empty third segment can occur with an unsecured token, but it remains unverified and should not be trusted.

Registered claims are displayed as information rather than enforced rules. For exp, nbf, and iat, the tool shows the NumericDate value and an ISO timestamp to make a Unix-seconds value easier to inspect. NumericDate is a timestamp convention, not a guarantee that the token is current. Whether a timestamp is acceptable depends on the issuing system, its configured clock skew, its intended audience, and the validation policy used by that system. The audience claim can be a string or an array; the tool renders the JSON value without deciding whether it matches your application. Custom claims remain visible in the raw payload, because JWT allows private claim names, but the page does not assign them special meaning.

Use a safe workflow: obtain a token only through an environment where you are authorized to inspect it, paste it into this local page, review the algorithm field and claims, then remove it from the input when you are done. Avoid pasting production credentials into shared screens, issue trackers, chat messages, screenshots, or third-party online decoders. Tokens can contain personal identifiers, tenant data, scopes, or other sensitive application details even when they are not passwords. This tool also cannot reveal content in an encrypted JWE, repair a broken token, discover a signing key, or tell you whether a signature is correct. If you need to validate a token, use a maintained JWT library in the service that owns the security decision and verify the algorithm, key, issuer, audience, expiry, and any application-specific requirements there. For nearby development tasks, JSON Formatter can make copied JSON easier to read, JSON Validator can check standalone JSON syntax, and Unix Timestamp Converter can inspect a timestamp independently. JWT Decoder remains focused on one private, decode-only task: showing what a compact token says without claiming that it is authentic.

Methodology & sources

The client splits a trimmed compact token into exactly three segments, validates unpadded RFC 4648 Base64url syntax, decodes only header and payload as fatal UTF-8, parses each as a JSON object, and lists present RFC 7519 registered claims. It checks the third segment's shape only and never verifies it, decrypts content, contacts a network endpoint, or makes an authentication decision.

Frequently asked questions

Does decoding verify that a JWT is valid?
No. This page only decodes the header and payload. It does not verify a signature, issuer, audience, expiry policy, or authorization.
Is my token uploaded?
No. Decoding happens in your browser. The tool does not send the token to a server or fetch signing keys.
Why are exp, nbf, and iat shown as dates?
RFC 7519 defines those values as NumericDate seconds. The ISO text is a reading aid, not a decision that the token is currently acceptable.

Related tools

Developer Tools guides

View all