FileGizmo Developer tools

Decode a JWT token

Decode JWT header and payload claims locally with explicit signature-verification warnings. The token is never transmitted, which matters if it is still valid.

Never uploadedYour file stays on this device

Simple by design

JWT decoder in three steps

Inspect the header and payload of a JSON Web Token without sending credentials to an online service. FileGizmo decodes the token’s Base64url sections into readable JSON, preserves the signature text, and highlights when a numeric expiration claim is earlier than the current device time.

Decoding is not verification. Anyone can construct or modify an unsigned token payload, so decoded claims must never be trusted by themselves. Production systems need server-side signature verification with an approved algorithm and key, plus issuer, audience, expiration, not-before, and application-specific checks. The interface keeps this warning next to every result.

The token stays in the current browser page and is not uploaded or stored. Use the decoder for local debugging and claim inspection, then remove sensitive tokens from shared screenshots, issue trackers, and messages. If a real credential has been exposed, revoke or rotate it according to your authentication system’s incident procedure.

Decoding is not verification, and the difference is the whole point. This tool reads the header and payload and shows you the claims inside them. It does not check the signature, because checking a signature requires the secret or public key that signed it, and a website that asked you for that key would be asking for the wrong thing entirely.

So treat what you see as a claim rather than a fact. Anyone can craft a token that says whatever they like; only the signature makes it trustworthy, and that check belongs on your server. The tool says this on screen rather than leaving it implied.

Expiry is calculated and shown, since exp and iat are Unix timestamps that nobody reads at a glance. Knowing a token expired forty minutes ago usually explains the failure you were investigating faster than anything else in the payload.

Malformed tokens are described specifically. A JWT has three dot-separated parts, and the usual problems are a truncated copy-paste, a missing segment, or Base64URL that has been mangled by an intermediate system. Each is reported as what it is.

The token is never transmitted, which matters more here than almost anywhere else on this site. A live token is a credential. Pasting one into an online decoder hands a working key to whoever runs it, and plenty of tokens remain valid for hours after somebody debugs with them.

  1. 1

    Paste a three-part JWT token

  2. 2

    Decode its header payload and signature text

  3. 3

    Review claims and expiration warning carefully

Good to know

Frequently asked questions

Does decoding verify the signature?

No. Only your server with the correct key and algorithm can establish token authenticity.

Is the token uploaded?

No. Base64url decoding happens entirely in your browser.

Does FileGizmo detect expiration?

It compares a numeric exp claim with the current device time and labels expired tokens.

Is it safe to trust decoded claims?

Never trust claims until the token signature, issuer, audience, and timing have been verified server-side.

Learn more

Related guides

Developer guideHow to decode a JWT safelyDecode JWT header and payload claims locally, distinguish inspection from verification, and avoid leaking bearer tokens into websites, screenshots, logs, and tickets.