Base64 / URL / JWT 인코더·디코더

Base64와 URL을 인코딩·디코딩하고 JWT의 헤더와 페이로드를 브라우저에서 확인합니다.

텍스트 또는 JWT

결과

사용 방법

"텍스트 또는 JWT" 칸에 입력값을 붙여넣거나 입력하세요. 인코딩할 일반 텍스트, 디코딩할 Base64 문자열이나 퍼센트 인코딩된 문자열, 또는 확인할 JWT를 넣을 수 있습니다.
텍스트와 Base64 사이를 변환하려면 "Base64 인코딩"이나 "Base64 디코딩"을, 퍼센트 인코딩을 적용하거나 풀려면 "URL 인코딩"이나 "URL 디코딩"을 누르세요. 결과나 오류 메시지는 "결과" 칸에 나타납니다.
토큰을 확인하려면 Bearer 접두어가 있든 없든 그대로 붙여넣고 "JWT 디코딩"을 누르세요. 헤더와 페이로드가 들여쓰기된 JSON으로 표시되고, 페이로드에 iat, nbf, exp 클레임이 있으면 "JWT 시간 클레임"에 나열되며, 숫자 값은 UTC와 현지 시간으로 변환되어 나옵니다.
"결과 복사"를 누르면 결과를 복사합니다. 인코딩을 되돌리려면 인코딩된 텍스트를 "텍스트 또는 JWT" 칸에 붙여넣고 그에 맞는 디코딩 버튼을 누르세요. 디코딩한 뒤 다시 인코딩해도 원래 값과 똑같이 돌아오지 않을 수 있습니다. URL-safe Base64나 패딩이 없는 Base64는 표준 문자로, 필요한 경우 = 패딩이 붙은 형태로 돌아오고, "URL 디코딩" 뒤에 남은 +는 "URL 인코딩"을 거치면 %2B가 됩니다.

자주 묻는 질문

붙여넣은 텍스트나 토큰이 어딘가로 전송되나요?

아니요. 인코딩과 디코딩은 브라우저에서 JavaScript로 실행되며, 입력한 내용은 LeedyBox로 전송되지 않습니다. 다만 JWT는 로그인 자격 증명으로 자주 쓰이며, 만료되거나 폐기되기 전까지는 토큰을 가진 사람이라면 누구나 쓸 수 있습니다. 유효한 토큰은 비밀번호처럼 다루고 스크린샷이나 채팅으로 공유하지 마세요.

"Base64 디코딩"에서 올바른 UTF-8 텍스트가 아니라는 오류가 나는 이유는 무엇인가요?

"Base64 디코딩"은 디코딩한 바이트를 UTF-8 텍스트로 보여 주며, 올바른 UTF-8이 아니면 이 오류를 내고 멈춥니다. PNG나 JPEG 이미지, 대부분의 PDF, 압축 데이터가 그렇고, Latin-1이나 Shift_JIS 같은 다른 인코딩으로 저장된 텍스트도 흔히 그렇습니다. 이 도구는 디코딩한 바이트를 파일로 저장하지 않으므로 텍스트를 담은 Base64에 사용하세요. data:image/png;base64,... 같은 데이터 URI는 콜론, 세미콜론, 쉼표가 Base64 문자가 아니어서 올바르지 않은 Base64로 거부됩니다.

URL-safe Base64와 패딩이 빠진 값도 처리하나요?

디코딩할 때는 그렇습니다. "Base64 디코딩"은 표준 문자(+와 /)와 URL-safe 문자(-와 _)를 모두 받고, = 패딩이 있든 없든 처리하며, 공백과 줄바꿈은 무시합니다. "Base64 인코딩"은 패딩이 붙은 표준 문자로 출력하므로, JWT에서 쓰는 URL-safe 형식이 필요하면 +를 -로, /를 _로 바꾸고 끝의 = 기호를 지우세요. 텍스트는 입력한 그대로 UTF-8로 인코딩되므로 끝에 공백이나 줄바꿈이 있으면 결과가 달라지며, 입력 칸의 줄바꿈은 LF로 인코딩됩니다.

"URL 인코딩"에 URL 전체를 넣어도 되나요?

대개는 권하지 않습니다. "URL 인코딩"은 JavaScript의 encodeURIComponent처럼 동작해 A–Z, a–z, 0–9와 - _ . ! ~ * ' ( )를 제외한 모든 문자를 퍼센트 인코딩하므로, URL의 구조를 이루는 / ? & = : #도 인코딩됩니다. 쿼리 매개변수 값 하나처럼 URL의 한 부분에만 사용하세요. 공백은 %20이 되고 ASCII가 아닌 문자는 UTF-8 바이트로 인코딩되어, 예를 들어 é는 %C3%A9가 됩니다.

더하기 기호가 공백으로 바뀌지 않는 이유는 무엇이고, "URL 디코딩"은 언제 오류를 내나요?

"URL 디코딩"은 JavaScript의 decodeURIComponent처럼 동작합니다. %XX 형태의 이스케이프 시퀀스를 디코딩하고 +는 그대로 두는데, 일반 URL 문법(RFC 3986)에서는 +가 공백을 뜻하지 않기 때문입니다. 많은 쿼리 문자열에 쓰이는 HTML 폼 데이터(application/x-www-form-urlencoded)는 공백을 +로 인코딩하므로, 그런 데이터는 디코딩하기 전에 +를 모두 공백으로 바꾸세요. 이 형식에서 실제 더하기 기호는 %2B로 쓰이므로 이 경우에도 올바르게 디코딩됩니다. 50% off처럼 % 뒤에 16진수 두 자리가 오지 않거나, %E2%82처럼 이스케이프된 바이트가 올바른 UTF-8이 아니면 오류가 납니다.

"JWT 디코딩"으로 어떤 토큰을 읽을 수 있나요?

서명된 JWT(JWS)에서 쓰는 header.payload.signature 형태의 세 부분짜리 compact 형식 토큰을 읽을 수 있으며, 서명 부분이 비어 있는 서명 없는 토큰도 포함됩니다. 서명 부분은 검사하지 않으므로, 디코딩되었다고 해서 토큰이 진짜라는 증거는 아닙니다. 암호화된 토큰(JWE)은 다섯 부분으로 되어 있고 키 없이는 페이로드를 읽을 수 없어 형식 오류가 납니다. 헤더나 페이로드가 Base64에서 JSON으로 디코딩되지 않거나, 페이로드가 JSON 객체가 아니라 문자열이나 숫자 같은 단순한 값이면 "JWT 해석 오류" 메시지가 나옵니다. 헤더나 페이로드에 9,007,199,254,740,991보다 큰 정수가 있으면 브라우저가 JSON을 읽을 때 반올림될 수 있으므로, 긴 숫자 ID는 마지막 자릿수가 다르게 표시될 수 있습니다.

exp, nbf, iat 시간은 어떻게 표시되고, 토큰은 언제 만료로 표시되나요?

값은 JWT 표준(RFC 7519)의 정의대로 초 단위 Unix 시간으로 읽어 UTC와 현지 시간으로 보여 줍니다. "만료됨"과 "아직 유효하지 않음"은 "JWT 디코딩"을 누른 순간의 기기 시계와 exp, nbf를 시계 오차를 허용하지 않고 비교한 결과이므로, 기기 시계가 틀리면 상태도 틀리게 나옵니다. 서버에 따라 작은 허용 오차(대개 몇 분 이내)를 두기도 하므로, exp나 nbf 시각 근처에서는 서버의 판단이 여기 표시된 상태와 다를 수 있습니다. "1700000000"처럼 문자열로 적힌 시간은 올바른 숫자형 Unix 타임스탬프가 아니라고 표시됩니다.