How to Decode a JWT Token Online (Safely, Step by Step)

By ToolSura DevTools Team, Senior Engineers · View profile

What decoding a JWT actually means

A JWT is three segments joined by dots, and the first two are [base64url, a URL-safe variant of base64](https://datatracker.ietf.org/doc/html/rfc4648) that trades the plus and slash characters for minus and underscore. Decoding simply reverses that encoding: the header and payload become ordinary JSON anyone can read. No secret, no key, no server involved. The [MDN base64 glossary entry](https://developer.mozilla.org/en-US/docs/Glossary/Base64) covers why the scheme is transport packaging rather than protection.

This is worth internalizing before your first decode: a JWT is a signed note, not a locked box. Anyone who intercepts a token can read its claims in one step. The signature guarantees the note came from the issuer and was not edited on the way; it says nothing about who may read it.

Decoding step by step with a real token

We generated this working token during research for the guide, so every value below is real output rather than a mockup:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTczMTUiLCJzY29wZSI6InJlYWQ6b3JkZXJzIHdyaXRlOnJldmlld3MiLCJpc3MiOiJodHRwczovL2FwaS5zaG9wZGVtby5leGFtcGxlIiwiYXVkIjoic2hvcGRlbW8td2ViIiwiaWF0IjoxNzc5MDAwMDAwLCJleHAiOjE3NzkwMDM2MDB9.dfvOcEicJ_6QqgzjTjhWPXzqSTrqEV4e3GxPONP4a3E

Step one: split on dots. Three segments appear: header, payload, signature. Two segments or four means a malformed token before any decoding starts.

The [visual walkthrough at jwt.io](https://jwt.io/introduction) shows the same split graphically. Step two: base64url-decode the header, which yields {"alg":"HS256","typ":"JWT"}. The algorithm claim matters later: it names how the signature must be checked, and servers should enforce it against an allowlist rather than trusting it blindly.

Step three: decode the payload, which produces:

{"sub":"user-7315","scope":"read:orders write:reviews","iss":"https://api.shopdemo.example","aud":"shopdemo-web","iat":1779000000,"exp":1779003600}

Step four: interpret the timestamps. Both values are what [RFC 7519 calls a NumericDate](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4): seconds since the Unix epoch in UTC. The iat of 1779000000 converts to May 17, 2026 at 06:40 UTC, and exp lands exactly one hour later at 07:40 UTC. Epoch seconds are the classic decoding gotcha; until converted, they are just large numbers.

Step five: leave the third segment alone. It is raw HMAC or public-key output, not JSON, and no decoder turns it into text. Its only use is verification, which requires the issuer's secret or public key.

What decoding tells you in practice

Debugging questions a decode answers

Symptom	What to check in the payload
Session keeps ending	Is exp set to a suspiciously short lifetime?
403 on a valid-looking token	Does scope or role actually include the permission?
Token rejected by another service	Does aud name that service, and iss the expected issuer?
Wrong user appearing	Does sub match the identity you authenticated?
Clock-related rejections	Is nbf in the future because of server clock skew?

Most JWT incidents in day-to-day development resolve at this level: the token said one thing, the service expected another, and decoding exposed the mismatch in seconds.

Decoding safely: the credential rule

A live token is a bearer credential: whoever holds it can call the API as its subject until it expires. That shapes the safety rules. Decode tokens from your own test environments freely; for production tokens, prefer tools that run entirely in your browser and avoid pasting live credentials into unfamiliar websites that could log them. Expired tokens are the safest to inspect, and rotating or revoking a token after debugging a live one costs little compared to the alternative. The [OWASP session management guidance](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) treats bearer tokens with the same caution for good reason.

Verification, by contrast, always happens server-side or with the issuer's public key, per the [JWT specification, RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). An online decoder that claims to verify your HS256 token without asking for the secret is simply skipping the check, because the math is impossible without it. The [validation best practices in RFC 8725](https://datatracker.ietf.org/doc/html/rfc8725) spell out which checks fall to the verifier.

A fast daily workflow

• Paste the token into the JWT decoder to split and read all three segments at once
• Convert iat and exp to local time before drawing any conclusion about expiry bugs
• Format surprising payloads with the JSON formatter when nested claims get hard to scan, a trick the [base64url definition in RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648) makes possible everywhere URLs appear
• Cross-check claim semantics against our [explanation of how JWT works](/blog/how-does-jwt-work/) before changing server code

The whole loop takes under a minute, which is why decoding is usually the first move whenever an authentication bug report mentions a token.

Read first, then verify

Decoding a JWT online is deliberately easy: split on dots, base64url-decode two segments, convert the timestamps, and the token's entire story sits in front of you. Keep the credential rule in mind, remember that the signature segment is for verification rather than reading, and let the decoded claims drive the debugging. When the question shifts from what is in this token to can I trust it, that is server-side verification work, and our [guide to how JWTs work](/blog/how-does-jwt-work/) picks up exactly there.