How to decode and create a JWT safely

Understand the three parts of a JWT

A JSON Web Token normally contains three Base64URL strings separated by dots: a header, a payload and a signature. The header describes the token type and signing algorithm. The payload contains claims such as a user identifier, issuer, audience, issued-at time or expiry time. The signature lets a receiving system detect changes when it has the correct verification key.

The header and payload are encoded, not encrypted. Anyone who receives the token can usually decode and read them. Do not put passwords, private keys, payment data or confidential personal information in a normal JWT payload. HTTPS protects a token while it travels, and careful storage protects it on the client; Base64URL itself provides no secrecy.

Common registered claims include iss for issuer, sub for subject, aud for audience, exp for expiry, nbf for not-before and iat for issued-at. Time claims normally use epoch seconds. Applications may add private claims, but producers and consumers must agree on their meaning and type.

Decode a token without assuming it is valid

Paste a three-part token into the decoder and select Decode token. The tool converts the first two Base64URL parts to formatted JSON and displays the third part as the signature text. This helps inspect claim names, troubleshoot formatting and convert time claims with the Epoch Converter.

A successful decode proves only that the first two parts contain readable JSON. It does not prove who created the token, whether the signature matches, whether the signing algorithm is allowed, or whether the token is current. An attacker can construct a well-formed token containing any name or role. Authorization decisions must use a trusted library that verifies the signature and validates required claims.

When debugging, confirm the alg header against the server's configured allow-list. Check that iss and aud exactly match expected values, and compare exp and nbf with the server clock. Be cautious with tokens copied from browser storage or request headers because they may grant account access until they expire.

Create an HS256 token for controlled testing

The encoder accepts a JSON payload and a signing secret. It creates a header with alg set to HS256 and typ set to JWT, encodes the header and payload, and signs their combined value using HMAC SHA-256 through the browser's Web Crypto API. The result is useful for local experiments and systems you control that explicitly expect HS256.

Start with non-sensitive example claims. Keep values in the types expected by the receiving application: time claims are normally numbers, while identifiers may be strings. JSON does not permit comments or trailing commas. If the tool reports invalid JSON, paste the payload into a structured editor or simplify it until the syntax is valid.

An HS256 verifier needs the same secret used for signing. Use a long, randomly generated secret and store it in an approved secret manager or protected server configuration. Do not commit it to Git, embed it in public frontend code, paste a production secret into screenshots, or share it through ordinary chat. Anyone holding that secret may be able to create accepted tokens.

Build complete server-side validation

Use a maintained JWT library on the server. Configure an explicit algorithm allow-list rather than trusting the alg value supplied by the token. Verify the signature before using claims, require the expected issuer and audience, enforce expiry and not-before times, and allow only a small clock tolerance when needed. Reject tokens with missing claims that your authorization model requires.

Keep authentication and authorization separate. A valid signature can establish that a trusted issuer created the claims, but the application must still decide whether the subject may perform the requested action. Roles can change before a token expires, so high-risk operations may need short token lifetimes, server-side permission checks or revocation controls.

Never log complete bearer tokens in production. Redact Authorization headers and query strings in application, proxy and analytics logs. If a real token is exposed, revoke or rotate the relevant session or key according to the system design. The SableApps page processes text locally, but the safest practice remains using sanitized test tokens whenever possible.

Quick checklist

• Treat decoded claims as unverified until a trusted server validates them.
• Never place confidential data in an ordinary JWT payload.
• Allow only the signing algorithms your application expects.
• Validate issuer, audience, expiry and required claims.
• Keep production tokens and signing secrets out of logs and screenshots.