Skip to content
Toolars
Explore
Report bug

Developer · Local utility

JWT Encoder / Decoder

Decode, sign, and verify JWTs across HS256-512, RS256-512, and ES256-512, with exp/nbf checks — keys and tokens never leave the tab.

Task path / input to outcome

Pick the operation

Runs locally · Nothing is uploaded

How JWT Encoder/Decoder works, privacy, and related tools

Task path / input to outcome

How to decode, sign, and verify a JWT

  1. 01

    Pick the operation

    Choose Decode to inspect untrusted claims, Sign to create a token, or Verify to check a token with your selected algorithm and key.

  2. 02

    Paste the token or write the payload

    For Decode and Verify, paste the compact three-segment token into Compact JWT, up to 64 KiB. For Sign, write the claims as a JSON object in JSON payload, up to 32 KiB; anything that is not a JSON object is refused.

  3. 03

    Load a sample to explore

    Press Load sample to see the full workflow with safe material: Decode gets a readable HS256 token, HMAC modes get a demonstration token with its secret, and asymmetric modes load a payload so you can paste your own matching key.

  4. 04

    Select the algorithm and key

    In Sign and Verify, choose an Algorithm from the HMAC, RSA, or ECDSA groups. HS algorithms take a Shared secret of at least 32 UTF-8 bytes for HS256 (48 for HS384, 64 for HS512); RS and ES take a PEM-encoded PKCS8 private key for signing or an SPKI public key for verification, up to 16 KiB.

  5. 05

    Run and read the verdict

    Run the selected operation. Decode displays untrusted header and payload data; Sign produces a compact token. Verify checks the signature and any exp/nbf conditions at the displayed browser time. Read the time cards and specific failure message, then correct the input and run again.

  6. 06

    Copy, download, and clean up

    Copy result puts the token or decoded JSON on the clipboard, and Download saves toolars-jwt.txt or toolars-jwt.json. Keys live in memory only: switching modes or algorithms clears the key field, and Reset empties everything.

Tool facts

Processing
In your browser
Input leaves this device
Never
Retention
Nothing is stored
Price
Free

Your input stays in the browser.

JWT Encoder/Decoder uses its verified local execution path and does not create a hidden input or output history.

Local execution

Runs inside the current browser tab.

No hidden processing

Active tool data never becomes a Toolars document record.

No account required

Use the core workflow without creating a profile. Favorites sync to your account after you sign in.

Immediate reset

Clear the tab and the active working data is gone.

What JWT Encoder/Decoder actually does

A login flow returns a token the API keeps rejecting, and the first question is what the claims actually say: Decode shows the header and payload in seconds. Later, a development service needs a short-lived test token signed with a local secret, and a staging key has to be checked against tokens that fail verification. JWT Encoder / Decoder reads, signs, and verifies tokens entirely in the browser. Production tokens and key material are pasted into a page that transmits nothing, and the keys never even touch browser storage.

Common questions

Which algorithms are supported?
HS256, HS384, and HS512 with a shared secret; RS256, RS384, and RS512 with PKCS8 and SPKI keys; ES256, ES384, and ES512 on their standard curves. Unsecured alg:none tokens are disabled, and Verify refuses a token whose header algorithm differs from the selected one.
Does decoding prove a token is genuine?
No. Decode only reads the token. Even a successful Verify result does not establish issuer identity, intended audience, revocation status or permission to use the token in an application.
What are the limits and key requirements?
Tokens up to 64 KiB, payloads up to 32 KiB, and keys or secrets up to 16 KiB. HMAC secrets must be at least 32, 48, or 64 UTF-8 bytes for HS256, HS384, and HS512; RSA and ECDSA keys must be PEM-encoded PKCS8 private keys for signing or SPKI public keys for verification.
What does Verify actually check?
Verify uses your selected algorithm and key, the browser clock and zero clock tolerance. exp and nbf are checked only when present; iat is not an age limit. Issuer, audience, key ownership, revocation and application rules are not checked. This is a snapshot, not an authorization decision. HMAC uses the exact UTF-8 secret, including spaces, without Base64 decoding.
Why is my key or secret rejected?
Three checks run before any cryptography: HMAC secrets must reach the minimum byte length for the chosen HS algorithm, private keys must be PEM-encoded PKCS8 values beginning with BEGIN PRIVATE KEY, and public keys must be SPKI values beginning with BEGIN PUBLIC KEY. Keys over 16 KiB are refused, and an ECDSA key must sit on the curve its ES algorithm names.
Are tokens or keys uploaded or stored?
No. Everything runs in the current browser tab; the signing engine loads on demand, keys stay in component memory, and nothing is written to browser storage, logs, or any network request. Reset clears all inputs and key material.

Continue in Developer

Related tasks, not a dead end.

Move into another focused workspace without returning to the full index.

Code to Image Converter

Export syntax-highlighted code as PNG or SVG for six languages with light and dark themes, line numbers, a window title, and 1x or 2x scale.

Create

URL Slug Generator

Turn titles into clean URL slugs with hyphens or underscores — accents stripped, ampersands expanded, non-Latin scripts preserved — live as you type.

Create

React Native Shadow Generator

Compare legacy shadow properties and boxShadow for React Native, tune iOS and Android output side by side, and copy the StyleSheet code.

Create

Base64 Encoder/Decoder

Encode Unicode text to Base64 or decode it back with live validation, URL-safe and UTF-8 options, and a swap button for round trips.

Convert