How-to Guide 6 min read

JWT Decoder Says Invalid Token? 7 Causes and How to Fix Them

Why a JWT decoder shows Invalid JWT format: the Bearer prefix, quotes, a cut-off token, 5-part encrypted tokens and more, with how to check each one in seconds.

invalid jwt formatjwt decode errorjwt malformedbearer token decodejwt has 5 parts jwe

The short answer

A JWT decoder shows "Invalid JWT format" when the text you pasted is not exactly three Base64URL-encoded parts separated by two dots, or when the first two parts do not decode to JSON. The most common causes are a leftover Bearer prefix, surrounding quotes, a token that was cut off when copied, and encrypted tokens that have five parts instead of three. Paste only the token itself into the JWT Decoder and it will show the header and payload.

What a valid JWT looks like

A signed JWT has three parts joined by dots:

header.payload.signature

  • The header and payload are JSON objects encoded with Base64URL (a URL-safe form of Base64 that uses - and _ instead of + and /, usually without = padding).
  • The signature is binary data, also Base64URL-encoded.

Encoded headers almost always start with eyJ, because that is how {" looks in Base64. If your text does not start with eyJ, the start has probably been cut or something has been added in front.

The decoder splits your text on the dots, checks there are exactly three parts, converts Base64URL back to normal Base64, decodes the header and payload and parses them as JSON. If any step fails, it shows "Invalid JWT format". It does not need the signature to decode, so even a token with an empty third part (ending in a dot) decodes.

The 7 common causes

1. The word Bearer is still in front

Tokens copied from an Authorization header look like Bearer eyJhbGci.... The space and the word "Bearer" become part of the first segment, which is no longer valid Base64. In testing, a token with Bearer in front fails to decode while the same token without it works.

Fix: delete Bearer and the space after it.

2. Quotes around the token

If you copy the token from JSON, a log line or code, you may pick up the quotation marks, as in "eyJ...w5c". The quote character is not allowed in Base64, so decoding fails.

Fix: remove the quotes at both ends. Also watch for a trailing comma copied from JSON.

3. The token was cut off

Long tokens are often truncated by terminals, log viewers, chat apps and email clients, or when only the visible part of a field is selected. If the last part is missing, the decoder sees two parts instead of three. If the cut falls inside the payload, it decodes to broken JSON.

Fix: copy the token again from the original source, for example the browser's developer tools (Network tab, request headers) or the cookie or storage panel.

4. Five parts: it is an encrypted token (JWE)

A JSON Web Encryption (JWE) token has five parts: header, encrypted key, initialisation vector, ciphertext and authentication tag. The payload is encrypted, so no decoder can show it without the decryption key. The JWT Decoder expects the three-part signed form and reports five parts as invalid.

Fix: you can decode only the first part (the header) to see the algorithm. To read the contents, the token must be decrypted by the system that holds the key.

5. It is not a JWT at all

Many services issue opaque tokens, random strings with no dots and no readable content. Others use session IDs, API keys or refresh tokens in their own formats. These look similar but are not meant to be decoded.

Fix: check whether the text has two dots and starts with eyJ. If not, it is probably not a JWT. Look at the service's documentation for what the token contains.

6. A character was changed or lost

A single changed character in the header or payload can break the JSON, for example when a token is retyped by hand or passed through a tool that changes characters. Some systems also replace + with a space in URLs, which corrupts Base64 that was not URL-safe.

Fix: use the original token. If it came from a URL, make sure it was URL-decoded once, not twice. The URL Encoder / Decoder can help check this.

7. Extra text pasted with it

Copying a whole log line, a cookie string such as token=eyJ...; Path=/, or a JSON object around the token adds characters that break the format.

Fix: paste only the part from eyJ up to the end of the signature.

What does not cause an error

Some things look wrong but are handled:

  • Spaces or a line break before or after the token are trimmed.
  • A line break in the middle, for example from a wrapped email, still decoded correctly in testing, because the browser's Base64 decoder ignores whitespace.
  • Missing = padding is normal for JWTs and is accepted.

When it decodes but looks strange

Accented or non-English characters look garbled

The decoder converts Base64 to text one byte at a time, so characters outside basic English (such as é, ñ or Devanagari script) in a claim like name can display as garbled symbols such as é. The token is fine; only the display is affected. The ASCII claims, such as sub, exp and iat, still read correctly.

"Valid JWT structure" but the server rejects it

The green "Valid JWT structure" label only means the token could be decoded. It does not check the signature. The decoder notes that signature verification needs the secret key, which should not be pasted into a web page. A token that decodes perfectly can still be rejected because the signature is wrong, the issuer or audience does not match, or it has expired.

It shows "Expired"

If the payload has an exp claim, the decoder compares it with your device's clock and shows Expired or Valid next to the expiry time. For how exp, iat and nbf work, read How to Check If a JWT Has Expired.

A quick checklist

  • Does it start with eyJ?
  • Are there exactly two dots?
  • No Bearer, quotes, commas or token= around it?
  • Was it copied in full from the original source?
  • If there are four dots (five parts), it is encrypted and cannot be read without the key.
  • Safety reminder

    A JWT's header and payload are only encoded, not encrypted. Anyone with the token can read them, which is why decoding works at all. Do not paste live production tokens for other people's accounts into any tool, do not share tokens in chats or tickets, and never put passwords or secrets in a JWT payload. The JWT Decoder runs in your browser, but treat tokens like passwords anyway.

    Related guides

    For the structure of JWTs and how they are used for login, see What Is a JWT Token and How Does It Work?. If you are decoding Base64 by hand and hitting errors, Base64 Decode Error? Fix Invalid Strings, Padding and URL-Safe covers the same character and padding issues. To turn exp and iat values into dates, use the Timestamp Converter.

    Frequently asked questions

    Why does my JWT show Invalid JWT format?

    The text is not three Base64URL parts separated by dots, or the header or payload does not decode to JSON. Common causes are a Bearer prefix, quotes around the token, a token cut off when copied, and five-part encrypted tokens.

    Do I need to remove Bearer before decoding a JWT?

    Yes. Paste only the token. The word Bearer and the space after it become part of the first segment and stop it decoding.

    Why does my token have five parts?

    It is a JWE (JSON Web Encryption) token. Its payload is encrypted, so it cannot be read without the decryption key. Only the first part, the header, can be decoded.

    Does a JWT decoder verify the signature?

    This one does not. Valid JWT structure only means the token decoded. Verifying the signature needs the secret or public key and should be done by your server or a trusted library.

    Why do names with accents look garbled after decoding?

    The decoder turns Base64 into text byte by byte, so non-English characters stored as multi-byte UTF-8 can display as symbols such as é. The token itself is fine.

    Try this tool on Lazyblink

    Put this guide into practice with our free online tool — no signup required.

    Open tool