Encoding

JWT Encoder/Decoder

Encode and decode JWT tokens — header, payload, HMAC signing, and standard claims.

A JWT (JSON Web Token) is a compact format for transmitting signed data, made of three dot-separated parts: a header, a payload, and a signature. This tool decodes any JWT and shows all three parts, and can also build a new token signed with HMAC.

Decoding does not verify the signature — reading a token's contents needs no secret key. Verifying the signature only matters when you need to trust the token as genuine.

How to use it

Common uses

Things to keep in mind

A JWT is not encrypted, only Base64URL-encoded — anyone can read the payload. Never put passwords or other secrets in it.

The signature protects against tampering, not against being read. For confidentiality you need extra encryption (JWE) or an HTTPS transport.

Article about this tool: JWT: token structure and what "decoding" a JWT actually means

Frequently asked questions

Does decoding a JWT verify its signature?

No. Decoding just base64url-decodes the header and payload so you can read the claims — it does not prove the token is authentic. To actually verify a signature you need the correct secret or public key entered here.

Is it safe to paste a real JWT into this tool?

Decoding and signing happen entirely in your browser — the token and any secret you enter are never sent to a server. Still, treat tokens from production systems carefully, since anyone who sees a decoded JWT can read its claims.

Why does my token show as expired even though it still works in my app?

The Expired/Valid indicator here only compares the exp claim to the current time — it doesn't check clock skew tolerances or other validation rules your server or library might apply.

What is the "alg: none" algorithm-confusion attack?

If a backend naively trusts the alg field from a token's header, an attacker can swap it to none, strip the signature — and a token with arbitrary data will pass verification. Robust libraries require the expected algorithm to be specified explicitly at verification time.

Why shouldn't I store a JWT in localStorage for sensitive sessions?

localStorage is accessible to any JavaScript running on the page, so it's vulnerable to XSS — a malicious script can steal the token. For session tokens, an httpOnly cookie, which JavaScript can't access, is safer.

Articles: Encoding

Base64: why encoding is needed and how it works

How Base64 turns binary data into ASCII text and where that is actually needed.

Base32: how it differs from Base64 and when it is more convenient

The case-insensitive Base32 alphabet and scenarios where it beats Base64.

URL Encode/Decode: percent-encoding in links

How special characters in URLs and query parameters turn into %XX sequences.

HTML Entities: how to safely output special characters on a page

Why the characters < > & need escaping and how that prevents broken markup.

Unicode Escape: what \uXXXX sequences mean

Where \u0041-style sequences in JSON and JS strings come from and what they mean.

ROT13 and the Caesar cipher: simple character substitution

Why shifting by 13 letters makes ROT13 self-inverse, and why anyone still uses it today.

Punycode: how internationalized domains work in DNS

How a domain with non-Latin characters gets converted into an ASCII form with the xn-- prefix.

Morse code: how text becomes dots and dashes

The principle behind encoding letters as dots and dashes, and where Morse code is still used today.

Data URI: when to embed images directly in code

How a data: URI embeds a file’s contents directly in HTML or CSS, and when that is worth it.

Gzip + Base64: compressing data for text-based transfer

Why compressed binary data also gets Base64-encoded before going into a text field.

XML Entities: escaping characters in XML documents

The five required XML entities without which a document breaks during parsing.