JWT Header Viewer
JWT Header Viewer decodes the first dot-separated segment and displays its JSON, commonly including alg, typ, or kid. It does not verify a signature, enforce an algorithm, resolve a key, validate token structure beyond decoding, or establish that any field is trustworthy. Treat every decoded value as untrusted input.
Runs locally — files stay on your deviceDoes decoding a JWT header verify the token?
No. Anyone can construct or alter an encoded header; trust requires cryptographic verification under an explicit policy.
The JOSE header describes processing metadata
A compact JWT commonly contains Base64url-encoded header and payload segments plus a signature or authentication segment. Decoding reveals text, not authenticity.
How it works
Paste a compact token. The tool selects the first segment, converts Base64url to Base64, parses decoded JSON, and formats it with indentation.
Key concepts
Header values are attacker-controlled until verification
Key identifiers and algorithms must be handled under an explicit verifier policy.
Base64url is encoding
It provides no confidentiality.
When to use it
- Inspect an alg or kid value during debugging.
- Read token metadata before independent verification.
- Explain compact JWT structure.
When not to use it
- Do not authorize access from decoded fields.
- Do not accept the header's alg without a server-side allowlist.
- Do not paste live bearer tokens into an untrusted environment.
Worked examples
Typical signed-token header
- Input
First segment encoding {"alg":"RS256","typ":"JWT"}- Expected output
Indented JSON
The display says nothing about signature validity.
Key identifier
- Input
Header containing kid- Expected output
kid is visible
The application must resolve it safely.
Malformed segment
- Input
Non-JSON first segment- Expected output
Error
Decoding or JSON parsing fails.
Common mistakes
Trusting alg from the token
Attackers control unverified metadata. Correction: Configure allowed algorithms independently.
Calling decoding validation
No signature key is used. Correction: Use a vetted JWT verification library.
Sharing bearer tokens
Possession may grant access. Correction: Redact or use synthetic tokens.
Best practices
- Use only synthetic or expired examples.
- Verify with an explicit issuer, audience, key, and algorithm policy.
- Treat kid and other header values as untrusted.
Related operations and differences
JWT Payload Viewer
Choose JWT Payload Viewer when you need to decode a JWT payload without verifying its signature.; use JWT Header Viewer specifically for jwt header.
Password Entropy Calculator
Choose Password Entropy Calculator when you need to calculate estimated entropy from an assumed character pool.; use JWT Header Viewer specifically for jwt header.
Password Strength Checker
Choose Password Strength Checker when you need to estimate password entropy without transmitting it.; use JWT Header Viewer specifically for jwt header.
SRI Hash Generator
Choose SRI Hash Generator when you need to generate a Subresource Integrity value for pasted content.; use JWT Header Viewer specifically for jwt header.
Basic Auth Header Generator
Choose Basic Auth Header Generator when you need to generate a Basic Authorization header locally.; use JWT Header Viewer specifically for jwt header.
HMAC Generator
Choose HMAC Generator when you need to create an HMAC using the browser Web Crypto API.; use JWT Header Viewer specifically for jwt header.
Limitations and privacy
- Decodes only the header JSON.
- No signature, encryption, issuer, audience, time, type, or algorithm validation.
- Does not support a complete JOSE security workflow.
The entered value is processed locally in this browser. Avoid using an untrusted device for real credentials or secrets.
Frequently asked questions
Is the signature checked?
No.
Is JWT content encrypted?
Not necessarily; ordinary signed JWT segments are readable.
Can I trust alg?
Not before policy-based verification.
What is kid?
A key identifier hint that must be resolved safely.