🔓 JWT 디코더

What is a JWT and why would I need to decode it?

A JWT (JSON Web Token) is a compact, URL-safe token used to securely transmit information between parties as a JSON object. It is commonly used for authentication and authorization in web applications and APIs. You need to decode a JWT to view its contents, which are typically encoded. Decoding allows you to inspect the payload (claims like user ID, expiration) and verify the header to understand the token's structure and validity without needing the secret key used to sign it.

What is the difference between decoding and verifying a JWT?

Decoding a JWT means converting the Base64Url-encoded parts (header and payload) into readable JSON. This is a public operation that anyone can perform on any token. Verifying a JWT is a security-critical step that checks the token's signature using a secret or public key to ensure it was issued by a trusted source and hasn't been tampered with. This tool performs decoding for inspection; for full security verification in a production environment, you must use your backend with the correct secret key.

What are the main parts of a decoded JWT?

A decoded JWT consists of three distinct parts, separated by dots in the encoded string. The Header contains metadata about the token type and the signing algorithm used (e.g., HS256, RS256). The Payload contains the "claims" or statements about an entity (typically the user) and additional data like issuer, subject, and expiration time. The Signature is used to verify that the sender of the JWT is who it says it is and to ensure the message wasn't changed along the way. When decoded, you can read the header and payload as JSON objects.

My token shows "Invalid token format." What does this mean?

This error indicates that the provided string does not conform to the standard JWT structure. A valid JWT must have three parts (header, payload, signature) separated by two dots (e.g., xxxxx.yyyyy.zzzzz). Common causes include: pasting an incomplete token, including extra characters like quotation marks, pasting an encrypted token (like a session cookie) instead of a JWT, or using a token that has been malformed. Ensure you are copying the full, exact token string from your application's request headers or storage.

What are common claims found in the JWT payload?

Claims are key-value pairs in the payload. Common registered claims include: iss (issuer), sub (subject, often a user ID), aud (audience), exp (expiration time, as a Unix timestamp), nbf (not before time), and iat (issued at time). Applications often add custom (private) claims like username, roles, or email to convey user-specific information. Decoding the payload allows you to see all these claims.

Is it safe to decode JWTs with online tools?

Decoding a JWT (reading the header and payload) is inherently safe as this data is only Base64Url encoded, not encrypted. Anyone with the token can decode it. However, you should never use an online tool to verify a signature with your secret or private key, as this requires sending the key to a third-party server, which is a major security risk. For inspection and debugging of non-sensitive tokens, decoding is fine. For production verification, always use trusted, server-side libraries.

What does the "alg" field in the header mean?

The "alg" (algorithm) field in the JWT header specifies the cryptographic algorithm used to sign the token, such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256). This tells the verifier which method to use to check the signature. It's crucial that your application validates this field and does not accept tokens with unexpected or "none" algorithms, as this can be a security vulnerability allowing token forgery.