In1.

JWT decoder

Paste a JSON Web Token and instantly read its header and payload as formatted JSON, with the issued, not-before and expiry times shown in human-readable form. Everything is decoded locally — nothing is uploaded.

Loading tool…
All Web tools

How to use JWT Decoder

  1. 1

    Paste your JWT

    Drop the full token, including both dots, into the input box.

  2. 2

    Read the header

    See the algorithm and token type as formatted JSON.

  3. 3

    Read the payload

    Inspect the claims, with issued, not-before and expiry times shown in readable form.

  4. 4

    Copy what you need

    Copy the decoded header or payload with one click.

See what is inside a JSON Web Token

A JSON Web Token, or JWT, is a compact string used to carry claims between systems — most commonly to prove who a user is after they log in. It looks like one long run of characters separated by two dots, and at a glance it tells you nothing. But it is not encrypted: the header and payload are simply Base64URL-encoded JSON, which means anyone holding the token can read what is inside. This decoder does that for you, splitting the token into its parts and turning the encoded segments back into readable, pretty-printed JSON. You can immediately see the algorithm and token type in the header, and the claims in the payload: who the token is about, who issued it, what permissions or roles it carries, and when it is valid. Being able to inspect a token quickly is essential when you are building or debugging authentication, and this tool gives you that view without writing any code or pasting the token into a command line.

Readable expiry, issued and not-before times

Some of the most important claims in a JWT are timestamps, and they are stored as raw Unix epoch numbers that are awkward to read. The 'exp' claim says when the token expires, 'iat' says when it was issued, and 'nbf' says the earliest time it is valid. Squinting at a ten-digit number to work out whether a token is still good is exactly the kind of friction that slows down debugging. In1 reads these claims and shows them as ordinary human-readable dates and times, and it flags an expired token directly, so you can tell at a glance whether the token you are looking at is current or stale. This is invaluable when you are chasing down an authentication problem: very often the answer is simply that the token has expired, and seeing that spelled out in plain language — rather than buried in an epoch integer — turns a confusing failure into an obvious one you can fix in seconds.

Decoding is not the same as verifying

It is important to be clear about what a decoder does and does not do, because misunderstanding it can be dangerous. This tool decodes the token: it reads the header and payload so you can inspect them. It does not verify the signature, which is the cryptographic check that proves the token was issued by who it claims and has not been tampered with. Verification requires the secret or public key that signed the token, and it must always be done on the server, never trusted to the client. So this decoder is the right tool for reading and debugging — seeing the claims, checking the expiry, understanding what a token contains — but it is not, and cannot be, a security check. Anyone can craft a string that decodes to whatever claims they like; only signature verification with the proper key tells you whether to trust it. Keeping that distinction clear is part of using JWTs safely, and the tool states it plainly so no one mistakes a successful decode for a valid token.

Private by design — decoded in your browser

JWTs are sensitive by their very nature. A token is often a bearer credential: whoever holds it can act as the user it represents until it expires. Pasting a live token into a website that sends it off to a server would mean handing your credential to a third party, which is precisely what you must never do. In1 decodes the token entirely in your browser using plain JavaScript. The token is never uploaded, never transmitted and never stored — it is split and Base64URL-decoded right on your own device, and it is gone when you close the tab. There is no account and no logging. This local-only design is not a nice-to-have for a JWT tool; it is the only responsible way to build one, because the whole point of inspecting a token is undermined if inspecting it leaks the token. You get the convenience of an instant decoder with the assurance that your credential stays exactly where it should: with you.

Who uses a JWT decoder?

It is an everyday tool for anyone working with modern authentication. Back-end and front-end developers decode tokens constantly while building and debugging login flows, checking that the claims, roles and expiry they expect are actually present. API developers and integrators inspect the tokens a service issues to understand what data and permissions they carry. QA testers verify that authentication behaves correctly by reading the tokens an app produces under different scenarios. Security engineers examine token contents while assessing how an application handles authorization. Support and operations staff decode a token from a bug report to see whether it has simply expired. Even people learning how JWTs work paste one in to demystify the format and see that the payload really is just readable JSON. For all of them, a decoder that shows the header and payload clearly, translates the timestamps, is honest about not verifying signatures, and keeps the token on the device is exactly the right tool for the job.

Get more from In1

Higher limits, batch processing and an API are on the way. Want early access?

Frequently asked questions

More Web tools