Developer tools · JWT decoder
JWT Payloads Are Not Encrypted: Anyone With the Token Can Read Them
· Why it matters
jwt privacy security
Base64url looks like scrambling but it is a reversible encoding. This post shows how readable a signed token's claims are, what belongs in them, and when you need JWE instead.
It looks encrypted — the misunderstanding that puts personal data in tokens
Long base64url segments look scrambled, which tempts teams to treat them as concealed data. The visual effect is misleading. Anyone holding a signed JWT can reverse the public encoding and read a JSON payload without possessing a signing or verification key.
ToolAcre demonstrates that property by decoding header and payload locally. It does not break encryption because ordinary JWS payloads are not encrypted. The ease of inspection should shape token design: encode only information that every legitimate holder and every accidental recipient may be able to see.
Signed, not sealed: a valid JWS can protect integrity, not payload confidentiality
A valid signature or MAC can let a properly configured verifier detect changes and relate the token to trusted key material. That is integrity and origin evidence within the verifier’s policy. It does not hide the protected content from the client, a proxy, a logger or anyone else who obtains the compact string.
The decoder cannot establish even that integrity because it never verifies. It shows what the token says about itself and reports signature bytes as unverified. This distinction avoids two opposite mistakes: assuming readable means forged, and assuming signed means confidential.
What a decoder shows — every claim, in plain JSON, with no key required
For header and payload, ToolAcre translates base64url, restores padding, recovers bytes as UTF-8 and parses JSON objects. No secret participates. The claims table then shows string values directly and structured values as JSON text, with descriptions for registered names such as `sub`, `aud` and `exp`.
That output is a transparency aid, not a truth oracle. A fabricated token can display the same subject and role as a legitimate one. Reading a claim requires no key; believing it requires successful verification plus issuer, audience, time and application checks in the consuming service.
Where tokens leak — logs, URLs, referrer headers, browser history and third-party scripts
Tokens can leak through application logs, copied support messages, URLs, referrer propagation, browser history, screenshots and scripts that can access the field. The exact paths depend on the system, but the payload’s readability means an expired or unusable token may still disclose personal or operational information.
Keep compact credentials out of URL query strings and routine logs. Redact them before sharing diagnostics. A signature does not sanitize the claims, and transport encryption only protects data while travelling between endpoints; authorized endpoints and accidental storage can still see plaintext token characters.
What belongs in a payload — identifiers and authorisation data, never secrets or data the holder should not see
Payloads commonly need identifiers and authorization context so recipients can make decisions after verification. They should not carry passwords, private keys or information the token holder must be prevented from reading. Minimize personal data and avoid convenient duplication of profile fields that no consuming service needs.
Roles and scopes are not secret merely because they are encoded, but they are still untrusted until verified. Design the claim set around least disclosure as well as least privilege. If a consumer does not need a field to perform its documented job, leaving that field out reduces every leakage consequence.
Worked example — decoding a sample token and listing exactly what a bystander would learn
Decode a synthetic payload containing `sub`, `email`, `tenant`, `roles`, `iat` and `exp`. A bystander learns the named account identifier, address, organization context, asserted permissions and timing without a key. Whether those assertions are genuine is a different question; their text is already disclosed.
Repeat the audit with each token profile your issuer produces, using only expired or test material. Record every field and its consumer. ToolAcre can help enumerate visible content, but it cannot decide lawful processing, sensitivity or retention rules for your organization.
Encrypted compact tokens have five parts, which this JWS decoder identifies rather than decrypts
When claims must remain confidential from the holder or intermediaries, an encrypted design may be required. Compact JWE has five parts and uses recipient decryption keys. ToolAcre identifies five segments as encrypted input and explains that it cannot reveal the contents without a key.
Encryption introduces key distribution, algorithm policy and operational failure modes beyond this decoder. It also does not remove the need for integrity and authorization checks. Choose it from a threat model rather than as a cosmetic upgrade to a payload that should have contained less data.
Takeaway: assume the payload is public — decode one of your own tokens in the ToolAcre JWT decoder and audit what it exposes
Assume an ordinary JWT payload is readable wherever the token travels. Use ToolAcre’s decode-only view to audit claim exposure, not to prove who issued the values. Remove secrets and unnecessary personal fields instead of relying on base64url to obscure them.
If confidentiality is genuinely required, use a mechanism whose documented security properties include it and manage the keys accordingly. Whether signed or encrypted, trust still comes from configured cryptographic validation and policy, never from the fact that a decoder displayed structured output.