Base64 디코딩

아래에 Base64 문자열을 붙여넣고 디코딩을 클릭하면 일반 텍스트로 변환됩니다. 모든 처리는 브라우저에서 로컬로 수행됩니다.

URL 안전 문자 집합, 줄바꿈, 빠진 패딩을 모두 받아들입니다.
복사됨!

Base64 디코딩이란?

Base64 디코딩은 Base64로 인코딩된 ASCII 문자열을 원본 바이너리 데이터 또는 텍스트로 다시 변환합니다. 이는 Base64 인코딩의 역과정입니다.

입력에 Base64 알파벳(A-Z, a-z, 0-9, +, /, =) 이외의 문자가 포함되면 디코딩이 오류와 함께 실패합니다.

디코딩에는 브라우저에 내장된 Base64 함수를 씁니다. 이 함수는 엄격해서 표준 문자 집합과 올바른 패딩을 기대하며, 그 밖의 것은 추측하지 않고 거부합니다. 디코딩된 바이트는 UTF-8 텍스트로 읽습니다.

디코딩되지 않는 문제를 쫓고 계신가요?

디코딩되지 않는 페이로드는 대개 원인이 아니라 증상입니다. 파이프라인 어딘가의 이중 인코딩, 선언 대신 가정된 문자셋, 아무도 예상하지 않은 바이트 위에 서명된 토큰 같은 것들이죠. 저희는 바로 그런 일을 합니다. 연동과 API, 그리고 그 사이에서 데이터를 넘기는 시스템에서요.

어디가 깨지는지 알려 주세요

자주 묻는 질문

제 Base64 문자열은 왜 디코딩되지 않나요?
거의 언제나 네 가지 중 하나입니다. 문자 집합 밖의 문자가 섞인 경우로, 대개 URL이 망가졌거나 복사하면서 엉뚱한 문장부호가 딸려온 것입니다. 다음은 한 문자가 남는 길이로, 온전한 바이트 수를 나타낼 수 없습니다. 다음은 URL 안전 문자 집합으로, 그 하이픈과 밑줄은 표준 디코더가 받지 않습니다. 마지막은 전송 도중 패딩이 떨어져 나간 경우입니다. 이 페이지는 브라우저 자체 디코더를 쓰며, 넷 모두에 엄격하고 추측 대신 거부합니다.
디코딩 결과가 읽을 수 있는 텍스트가 아닌 이유는 무엇인가요?
그 바이트가 애초에 텍스트가 아니었기 때문입니다. Base64는 임의의 데이터를 실어 나르므로, 담긴 것이 이미지나 PDF, 압축 아카이브, 직렬화된 구조일 수 있습니다. 이 페이지는 디코딩된 바이트를 UTF-8 텍스트로 읽으므로 텍스트가 아닌 것은 비거나 깨져 나오며, 그것 자체가 답입니다. 텍스트를 기대했다면 이중 인코딩을 의심하세요. 이미 Base64였던 데이터를 무언가가 다시 Base64로 감쌌을 수 있습니다.
패딩이 없는 Base64도 디코딩할 수 있나요?
여기서는 안 됩니다. 패딩은 길이가 4의 배수가 아닐 때 디코더가 끝을 알 수 있게 하려고 존재하며, 브라우저의 디코더는 이를 요구합니다. 등호가 URL과 파일 이름에서 거추장스러워 많은 시스템이 떼어 내는데, 문자열이 그런 경우라면 길이가 4로 나누어떨어질 때까지 등호를 붙이면 디코딩됩니다. 한 문자가 남는 길이는 이 방법으로 고칠 수 없습니다. Base64 한 문자는 6비트만 담아 온전한 바이트를 만들 수 없기 때문입니다.
민감한 데이터를 이 페이지에 붙여 넣어도 안전한가요?
디코딩은 브라우저에서 돌아가고 어디로도 전송되지 않으므로, 위험한 것은 이 페이지 자체가 아닙니다. 위험은 그 기기의 나머지 전부입니다. 브라우저 확장은 페이지 내용을 읽을 수 있고, 붙여 넣은 비밀은 클립보드 기록에 남기 쉽습니다. 운영 중인 실제 자격 증명이라면 로컬에서 디코딩하세요. 명령줄 도구는 모든 유닉스 기기에 이미 있고, PowerShell에도 동등한 수단이 있습니다.
data URI는 어떻게 디코딩하나요?
먼저 접두사를 떼어 내세요. data URI는 data라는 낱말, MIME 타입, 페이로드가 Base64임을 알리는 표시, 그리고 페이로드 본문으로 이뤄지며, 디코딩할 수 있는 것은 마지막 부분뿐입니다. 쉼표까지 포함해 앞을 모두 지우고 나머지를 붙여 넣으세요. 한 글자를 더 자르거나 덜 자르는 것이 그 뒤 디코딩이 실패하는 흔한 원인입니다.