Quick summary
Understand JSON Web Tokens, header-payload-signature structure, claims, signature verification, expiration and common JWT security mistakes. This guide gives you a clear, practical explanation before you use the related online tool.
What a JWT is
A JSON Web Token is a compact token format commonly used to carry claims between systems. A typical signed JWT is represented as three Base64URL-encoded segments separated by dots: header.payload.signature. JWT describes a token format; it does not by itself define your application’s authentication or authorization design.
Header, payload and signature
The header usually identifies the token type and signing algorithm. The payload contains claims such as subject, issuer, audience and expiration, plus application-specific claims. The signature lets a verifier detect unauthorized changes when verification is performed with the correct key and expected algorithm.
Decoding is not verification
The header and payload can be Base64URL decoded without possessing a signing secret or private key. That makes decoding useful for inspection and debugging, but readable claims are not trustworthy until the token’s signature and validation rules have been checked by the receiving application.
Common registered claims
Frequently used claims include iss for issuer, sub for subject, aud for audience, exp for expiration, nbf for not-before and iat for issued-at. Applications should define which claims are required and validate them rather than merely displaying them.
Signature verification
Verification should use a trusted key and explicitly allowed algorithm. The application must reject invalid signatures and should not accept an algorithm simply because the token header requests it. Key rotation, issuer metadata and asymmetric versus symmetric signing depend on the identity architecture.
Expiration, issuer and audience
A valid signature alone is not enough. Check expiration and not-before rules with an appropriate clock-skew policy, verify that the issuer is trusted, and confirm the audience matches the intended API or application. These checks prevent a correctly signed token from being accepted in the wrong context.
Do not put secrets in JWT payloads
Signed JWT payloads are normally readable, not encrypted. Avoid placing passwords, private keys or other secrets in claims. Minimize personal or sensitive data and consider token lifetime and logging practices because tokens may appear in browser storage, proxies or diagnostic systems.
Safe debugging workflow
When debugging, inspect the token structure and claims, but avoid pasting live production credentials into untrusted services. FormatForge’s JWT Decoder is useful for examining token content; decoding does not validate authenticity, authorization or server-side acceptance.
Continue with a free tool
Related FormatForge tools
JWT Decoder
Decode JWT headers and payload claims locally for development and API troubleshooting.
Open tool →Base64 Decoder
Decode Base64 strings into readable text while checking malformed input during API and integration debugging.
Open tool →JSON Studio
Format, validate, view, compare, split, merge and analyze JSON in one professional workspace.
Open tool →Explore the complete workflow
Continue from this guide to the broader category or curated collection to find related tools and supporting workflows.
Frequently asked questions
Can anyone decode a JWT?
For ordinary signed JWTs, the header and payload are encoded rather than encrypted and can usually be decoded without the signing key.
Does decoding a JWT verify it?
No. Verification requires checking the signature and the application’s required claims and policies.
What does exp mean in a JWT?
exp is the expiration-time claim and indicates when the token should no longer be accepted, subject to the verifier’s validation rules.
Should passwords be stored in JWT claims?
No. Signed JWT payloads are generally readable, so secrets should not be placed in them.
What should an API validate besides the signature?
Typically expiration/not-before timing, issuer, audience and application-specific requirements, in addition to the signature and expected algorithm.
Keep learning
Related guides
Developer
Base64 Encoding Explained: Text, Images, Data URLs and Decoding
Understand what Base64 encoding does, why encoded data grows in size, how images and Data URLs use Base64, and when to encode or decode it.
Developer
Cron Expression Guide with Examples: Minutes, Hours, Days and Scheduling
Learn cron expression fields with practical examples for hourly, daily, weekly and monthly schedules, plus common portability and timezone mistakes.
Developer
Regex Tester Guide for Beginners
Learn how regex patterns work and how to test them safely.
Developer
JSON to C# Class: Why .NET Developers Use It
Learn how JSON to C# class conversion helps .NET developers create models and DTOs.