Base64 Decoding: Reading JWTs, API Responses, and Encoded Data
Base64 decoding is something every developer encounters regularly — inspecting a JWT token, reading an API response that contains encoded data, debugging an OAuth flow, or examining a SAML assertion. The encoded strings look like noise until you decode them. This guide covers the practical scenarios where you'll need Base64 decoding and how to handle the quirks that trip people up.
Decoding JWT Tokens
A JSON Web Token has the format header.payload.signature. All three parts are Base64url-encoded. The header and payload are JSON objects; the signature is the raw cryptographic signature bytes.
To read a JWT's contents, decode the second part (payload). Paste the full JWT into this decoder and click "Decode JWT payload" — the tool will split on the dots, extract the payload, Base64url-decode it, and pretty-print the JSON.
Common JWT payload claims you'll find:
sub— Subject (usually the user ID)iat— Issued At (Unix timestamp)exp— Expiration (Unix timestamp — convert to a date to check if expired)iss— Issuer (your auth server URL or name)aud— Audience (which service the token is for)- Custom claims — roles, permissions, tenant IDs, whatever your auth system adds
Important reminder: decoding the payload does not verify the signature. You're reading the claims the token asserts, but you cannot confirm those claims are authentic without verifying the HMAC-SHA256 or RSA signature against the issuer's key. Use your backend library for signature verification.
Decoding API Tokens and Credentials
Many API tokens and secrets are Base64-encoded for safe transport. AWS access keys embedded in config files, database connection strings, and service account JSON files from Google Cloud all contain Base64-encoded values in various fields.
A common debugging scenario: you receive an Authorization: Basic ... header and want to see the credentials inside. Strip "Basic " from the front, paste the remainder here, and you'll see username:password. This is why Basic Auth over HTTP is insecure — anyone who intercepts the header can decode it in seconds.
Reading SAML Assertions
SAML (Security Assertion Markup Language), used in enterprise SSO, sends authentication assertions as compressed, Base64-encoded XML. The SAMLResponse parameter in SSO redirects is Base64-encoded (and often zlib-compressed). Decoding gives you the XML assertion containing user attributes, session data, and signature information.
When debugging SAML integrations — verifying attributes, checking NameID format, inspecting audience restrictions — you'll spend a lot of time decoding these assertions. This tool handles the Base64 step; for SAML-specific parsing with deflate decompression, use a dedicated SAML debugger.
Debugging Encoded Query Parameters
Some web applications encode entire JSON objects as Base64 in query parameters. For example: ?state=eyJ1c2VyIjoiYWxpY2UifQ==. This is common in OAuth flows (the state parameter) and redirect parameters. Decode the value to see what's inside — often it's a JSON object with a return URL, CSRF token, or session identifier.
Note: query parameter Base64 values are often Base64url-encoded (no + or /) and may have padding stripped. This tool handles all variants automatically — just paste and decode.
Certificate and Key Inspection
PEM files (TLS certificates, RSA keys, SSH keys) are Base64-encoded DER data wrapped in header/footer lines like -----BEGIN CERTIFICATE-----. To inspect the raw bytes, strip the header/footer lines and decode the Base64 block. The result is DER-formatted binary — you'd need an ASN.1 parser to make sense of it, but the decode step is pure Base64.
Need to encode text instead? Use the Base64 Encoder.