Base64 URL 디코더 파서

네. data URL 또는 원본 Base64 이미지 문자열을 붙여넣으면 감지된 MIME 타입과 크기와 함께 이미지 미리보기를 보여줍니다.

네. 디코딩 모드에서는 URI 디코딩 전에 plus 기호를 공백으로 해석하며, 일반적인 폼 인코딩 동작과 일치합니다.

네. JWT 모드에서 헤더, 페이로드, 서명 관련 세그먼트를 각각 선택해 디코딩할 수 있습니다.

표준 Base64(RFC 4648 4절)는 +와 /를 사용하는데, 이들은 URL 예약 문자와 충돌합니다. URL-safe 알파벳(5절)은 이들을 -와 _로 바꿉니다. JWT는 항상 URL-safe 알파벳을 사용합니다 - 그래서 토큰 서명에는 +나 /가 절대 없습니다. 이 도구는 두 알파벳을 모두 자동 감지합니다.

Base64는 3바이트를 4문자로 인코딩하므로, 3의 배수가 아닌 입력은 길이를 4의 배수로 유지하려고 =로 패딩합니다. = 하나는 남은 바이트 2개, = 두 개는 1개를 뜻합니다. 길이를 다른 경로로 알 수 있다면 패딩은 안전하게 생략할 수 있습니다 - JWT 세그먼트가 정확히 그렇게 합니다 - 디코더가 자동으로 복원합니다.

Base64 자체는 무손실이지만, 흔한 JavaScript btoa() 함수는 Latin-1 문자만 받고 나머지에서는 예외를 던집니다. 올바른 방법은 먼저 UTF-8로 인코딩(TextEncoder)한 뒤 그 바이트를 Base64하는 것입니다. 이 도구가 이 파이프라인을 자동으로 처리하므로 중국어, 아랍어, 이모지 텍스트도 손상 없이 왕복합니다.

세 가지 신호를 확인하세요: 문자 집합이 A-Z, a-z, 0-9, +, /(또는 URL-safe -와 _)뿐이고, 패딩을 복원하면 길이가 4의 배수이며, 디코딩 결과가 의미 있는 바이트인지입니다. abcd 같은 일반 문자열도 유효한 Base64일 수 있어 100% 확실한 방법은 없습니다 - 문맥이 중요합니다.

아니요. Base64는 누구나 비밀 없이 디코딩할 수 있는 가역 인코딩입니다 - 기밀성은 전혀 없습니다. 비밀번호나 API 키 보호에 절대 사용하지 마세요. 보호하려면 전송 중 TLS와 AES-256-GCM 같은 진짜 암호를 쓰세요. Base64의 유일한 역할은 바이너리 데이터를 텍스트 채널에 안전하게 실리게 하는 것입니다.