Pasting a JWT into jwt.io is safe enough for test tokens and expired tokens, and a poor idea for a live production token. The bigger risk sits in the optional signature check: it asks for your signing secret, and that secret can mint tokens for every user. Keep live tokens and secrets on your own machine.
What you actually hand over when you paste a token
A pasted JWT is a working credential. RFC 6750 defines a bearer token as one where "any party in possession of the token" can use it like anyone else who has it. No key or proof of possession is needed.
So a valid access token copied into the wrong place is a login. The same RFC tells client code to make sure bearer tokens "are not leaked to unintended parties."
The payload is readable too. RFC 7519 builds a JWT from base64url-encoded parts separated by dots, and signing doesn't hide them. RFC 6750 also warns that tokens "may contain authentication and attribute statements that include sensitive information", such as email addresses, tenant IDs or roles.
Two things decide your risk:
- Is the token still valid? Check
exp. An expired token can't open anything, though its claims can still be personal data. - What can it do? A read-only token for a test tenant is very different from an admin token for production.
Is jwt.io safe for decoding tokens?
The debugger is a reasonable choice for sample, test and expired tokens, as long as you treat the site as a third party. As of November 2026, the site offers to "decode, validate, and verify" a pasted token, and it also has an Encoder tab for creating tokens.
The trouble with any hosted decoder is that you can't see its code at the moment you paste. A page can change between visits, load third-party scripts, or run alongside a browser extension that reads form fields. That holds for every web tool, ours included. So ask what happens if this token leaks, not whether the site is honest.
For a test token, nothing much. For a live production token, someone could act as that user until it expires.
The bigger risk: the signing secret field
Pasting the secret is worse than pasting the token. One token is one user for a limited time. The secret is every user for as long as the key lives.
The debugger's signature panel says "Enter the secret used to sign the JWT below" for HS256 tokens. RFC 7518 section 3.2 shows why that matters: the HS256 MAC is both generated and validated "using the shared key." Whoever can check an HS256 signature can also forge one.
That gives you a simple rule for the kinds of input you might paste:
| What you paste | What leaks if the page misbehaves | Safe for a web tool? |
|---|---|---|
| Test or expired token | Claims only | Yes |
| Live production token | One user's access until exp |
No, decode locally |
| HS256 shared secret | Anyone can sign valid tokens | Never |
| RS256 or ES256 public key | Nothing secret | Yes |
Weak secrets add another problem. RFC 8725 says weak symmetric keys "are vulnerable to offline brute-force or dictionary attacks once an attacker gets hold of such a token." It also says human-memorizable passwords MUST NOT be used directly as an HS256 key, and RFC 7518 requires a key of at least 256 bits for HS256. If you're tempted to type a short password into a verify box to "just check", the key is already too weak.
My take: that secret field is a demo feature. Verify real tokens in code, with the key loaded from your secret store, and never type the key into a browser.
How to check what any JWT tool sends
You can test a web decoder's claim yourself in under a minute. Do it with a fake token first, never a real one.
- Open the tool, then open DevTools and select the Network tab.
- Clear the request list so only new traffic shows.
- Paste a sample token and wait a few seconds.
- Look at each new request. Search the request bodies and URLs for a piece of the token's payload.
- Reload and repeat after the site updates, because a page can change.
No new request carrying the token means the decode ran in your browser. Analytics and font requests are normal. None of them should contain your input. RFC 6750 adds a related warning: tokens in page URLs can end up in "browser history, web server logs, and other data structures", so a tool that puts the token in its URL is a red flag.
The online formatter safety guide walks through the same check for JSON tools.
Safer ways to read a live token
The safest decoder for a production token is one that never leaves your machine. You have three practical options.
- Browser console or Node. Split the token on the dots and base64url-decode the first two parts. Our guide on decoding a JWT safely has a short function that handles the
-and_characters and UTF-8 text correctly. - Terminal. The payload is just base64url, so the commands in the Base64 command line guide work once you swap
-for+and_for/. - Python. The standard library can do it too; see decoding Base64 in Python.
If you prefer a page, our JWT decoder decodes in the browser: its tool code makes no network requests, and pasted input isn't saved. It shows the header, payload, signature and iat/exp times with an expired or valid flag. It does not verify signatures, so it can't tell you a token is genuine. The page also loads Google Analytics, Google Fonts and Font Awesome from third-party servers.
What to do if you already pasted a live token
If you pasted a live token into a third-party site, treat it as possibly exposed and act on what it can do.
- Short-lived access token: check
exp. If it expires soon and the site checks out in the Network tab, the risk is small. - Long-lived or refresh token: revoke it, or sign the user out so the session ends early.
- Signing secret: rotate the key. Every token signed with the old secret should stop validating, and users will need to sign in again.
FAQ
Can someone use my JWT if they see it?
Yes, while it is still valid. A JWT sent as a bearer token works for anyone who holds it, with no extra key or proof needed, until it expires or the server revokes it.
Is a JWT encrypted?
A normal signed JWT is not encrypted. Its header and payload are base64url-encoded JSON, so anyone holding the token can read every claim in it.
Is it safe to paste a public key into a JWT debugger?
A public key is meant to be shared, so pasting it exposes nothing secret. The risks are the token you paste next to it and, for HS256 tokens, the shared secret.
How can I check whether a web tool sends my token anywhere?
Open DevTools, select the Network tab, clear it, then paste a sample token. If no new request carries the token, the decode ran in the page. Repeat the check after the site updates.