Authorization Header Decoder
Paste an HTTP Authorization header and see what it actually carries: the auth-scheme, Basic credentials decoded into username and password, a Bearer token's structure, and Digest or AWS SigV4 parameters. Decoded in your browser — the credentials never leave your device.
About this tool
An HTTP Authorization header is two things glued together: an auth-scheme
and the credentials that follow it (RFC 7235). This tool takes them apart and
tells you what each half means, whichever scheme you paste.
Paste a whole header line (Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==), just the value
(Basic …), or even a naked base64 credential with no scheme at all — it is
accepted and reported as such. Line breaks from a wrapped log line are treated as
spaces. Everything runs in your browser via WebAssembly; the header is never
uploaded.
What it decodes
- Basic — base64-decoded and split on the first colon into username and password (RFC 7617). A colon inside the password is kept where it belongs.
- Bearer (also
DPoP,Token,ApiKey) — the token's structure: JWT, JWE or opaque, segment count and per-segment lengths, character set, and the decoded JOSE header (alg,typ,kid). Payload claims are deliberately not decoded — see the FAQ. - Digest — every
name=valueauth-param parsed into a map, quoted values unescaped:realm,nonce,qop,nc,cnonce,opaque,algorithm,uri,response. - AWS4-HMAC-SHA256 — the
Credential=scope split into access key ID, date, region, service and termination string, plusSignedHeadersandSignature. - Negotiate / NTLM — the base64 blob is decoded and identified from its signature, including the NTLMSSP message type (1 negotiate, 2 challenge, 3 authenticate).
- Anything else —
Hawk,Signature,HOBA,Mutual,SCRAM-SHA-256,vapid,OAuthand unknown custom schemes are parsed with the generic RFC 7235 grammar, so a custom scheme still yields a structured result.
Options
- Output format —
json(default) returns every field plus the warning list;textreturns alignedkey: valuelines;tablereturns an ASCII field/value table for pasting into a ticket or a chat message. - Mask secrets — replaces the password, bearer token,
response,signature,macand the raw credential string with asterisks while keeping the reported lengths, so you can share a parse without sharing a secret. - Strict — turns every warning (non-canonical scheme spelling, missing scheme, missing colon, unpadded or URL-safe base64, non-UTF-8 credentials, unknown scheme) into an error instead. Useful when checking that a client emits a clean header.
Limits and edge cases
- Input is capped at 8192 characters — far above any real header, including SPNEGO blobs.
- The first colon separates username from password; a password containing colons round-trips correctly and is flagged so you know why.
- Decoded credentials that are not valid UTF-8 are shown with
U+FFFDfor the invalid bytes and markedvalid_utf8: falserather than rejected. - Both standard (
+ /) and URL-safe (- _) base64 alphabets decode, with or without=padding; unusual alphabets and missing padding raise a warning. - Nothing is verified. A
Digestresponse, a JWT signature or a SigV4 signature is reported, never checked — verification needs the shared secret or key. - The scheme is matched case-insensitively; the spelling you pasted is reported as
schemeand the registered spelling asscheme_canonical.
FAQ
Are my credentials uploaded anywhere?
No. The decoding runs inside your browser tab as WebAssembly — the header never leaves your device, and there is no server-side step. That said, base64 is encoding, not encryption: if a header has been pasted somewhere it shouldn't, rotate the credential rather than trusting that it stayed hidden.
Why doesn't it show the JWT payload claims?
By design. A Bearer token here is described structurally — JWT vs opaque,
segment lengths, character set, and the JOSE header with alg/typ/kid. Claim
inspection and expiry validation are a different job with different options
(exp/nbf handling, clock leeway), so reach for a dedicated JWT decoder for
those. Everything this tool reports is about the header, not the token's
contents.
What happens if my password contains a colon?
It stays in the password. RFC 7617 splits the decoded username:password string
on the first colon only, so user:pa:ss decodes to username user and
password pa:ss. The result includes a warning pointing this out, because it's a
common source of confusion. A colon in the username is impossible to express —
there would be no way to tell where the username ended.
Can I paste the whole header line, or just the value?
Either. Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==, Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== and the bare QWxhZGRpbjpvcGVuIHNlc2FtZQ== all
work. Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== is accepted too. If the name is something else
entirely, it's still parsed with the same grammar and you get a warning. A value
with no scheme at all is guessed (JWT-shaped → Bearer, base64 of user:pass →
Basic) and flagged, since a real header must start with a scheme.
What does "mask secrets" actually hide?
The Basic password, the bearer token, the raw credential string, and the
secret-bearing auth-params (response, signature, mac, cnonce, sig).
Non-secret context — the scheme, the username, realm, nonce, qop, the AWS
credential scope, and every reported length — is kept, so a masked result is
still diagnostic enough to paste into a bug report.
Does it verify the signature or check whether the token is valid?
No. This is a parser, not a verifier. It will tell you that a Digest header
carries a response, that a JWT has three segments and an HS256 header, or
that a SigV4 header signs host;x-amz-date — but confirming those values are
correct requires the shared secret, the private key, or the full canonical
request, none of which belong in a browser tool.
What is "strict" mode for?
It turns every warning into a hard error, so it doubles as a lint for header-emitting code. Run a client's header through with strict on: if it comes back clean, the scheme is spelled canonically, the base64 is padded and uses the standard alphabet, the credentials are valid UTF-8 with a proper colon, and the scheme is one that's actually registered. Anything less and you get the reason.
Developer & Automation Access
Run it from the terminal
Same engine as this page, headless — via the gizza CLI:
gizza tool authorization-header-decode "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=="New to the CLI? Get gizza →
Open it by URL
Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:
https://gizza.ai/tools/authorization-header-decode/?header=Authorization%3A%20Basic%20QWxhZGRpbjpvcGVuIHNlc2FtZQ%3D%3D&format=json&mask_credentials=true&strict=trueMachine-readable descriptor: tool.json — title + parameters JSON Schema for agents.