← Back to blog

Reading JWTs safely — what a decoder shows and what it does not

A JWT is three Base64url segments joined with dots: header.payload.signature. Any decoder — including the one on this site — pulls the header and payload out of those segments and shows them to you as JSON. That is genuinely useful for debugging. It is also the single most misunderstood thing about the format.

Decoding is not validation

The decoder did not check the signature. It did not check that the token was signed by someone you trust. It did not check that the token is still within its validity window. It showed you what is inside the envelope, nothing more. If your application code accepts a token because the payload looks right, you have a vulnerability — an attacker can forge a payload with whatever claims they like, encode it, and your code will accept it.

Validation is a separate step that requires the issuer's public key (for asymmetric algorithms like RS256/ES256) or shared secret (for symmetric HS256). Real validation:

The classic mistakes

What the decoder is good for

Debugging. When a user reports "the API says I am not allowed," paste their token, look at the claims, and check the expiry. When a third-party integration sends you a token and you want to know what is in it. When you are reading a tutorial that mentions a claim like scope and you want to see how your auth provider populates it. The decoder runs locally in your browser — the pasted token is never sent anywhere — so it is safe to use with production tokens you would not paste into a random web form.


JWT를 안전하게 다루는 법 — 디코더가 보여주는 것과 보여주지 않는 것

JWT는 점(.)으로 연결된 세 개의 Base64url 세그먼트입니다 — 헤더.페이로드.서명. 어떤 디코더든 — 이 사이트의 디코더 포함 — 앞 두 세그먼트에서 헤더와 페이로드를 추출해 JSON으로 보여줍니다. 디버깅에는 정말 유용하지만, 동시에 이 포맷에 대해 가장 많이 오해받는 부분이기도 합니다.

디코딩은 검증이 아니다

디코더는 서명을 확인하지 않았습니다. 신뢰하는 발급자가 서명했는지도, 토큰이 아직 유효 기간 안에 있는지도 확인하지 않았습니다. 그저 봉투 안에 든 내용을 펼쳐 보여줬을 뿐입니다. 만약 애플리케이션 코드가 페이로드가 "그럴듯해 보인다"는 이유로 토큰을 받아들인다면, 그 코드는 취약점입니다 — 공격자가 원하는 클레임으로 페이로드를 위조해서 인코딩하면 그대로 받아들여집니다.

검증은 디코딩과는 별개의 단계이며, 비대칭 알고리즘(RS256/ES256)이라면 발급자의 공개 키, 대칭 알고리즘(HS256)이라면 공유 시크릿이 필요합니다. 실제 검증이 하는 일:

자주 하는 실수

그럼 디코더는 언제 쓰나

디버깅입니다. 사용자가 "API가 권한 없음이라고 합니다"라고 신고했을 때 토큰을 붙여 넣고 클레임을 확인하고 만료 시각을 보는 용도. 외부 서비스가 보낸 토큰에 어떤 정보가 들어 있는지 확인할 때. 문서에 등장한 scope 같은 클레임을 인증 공급자가 어떻게 채우는지 보고 싶을 때. 디코더는 브라우저 안에서만 동작합니다 — 붙여 넣은 토큰은 외부로 전송되지 않습니다 — 그래서 평소 같으면 임의의 웹 폼에 붙여 넣기 망설여질 운영 토큰도 안심하고 사용할 수 있습니다.