Base64 디코딩
Base64를 붙여 넣으면 원래 모습 그대로 돌려드립니다. 텍스트, 이미지, PDF, 무엇이든요. 깨진 패딩, 줄 바꿈, URL 안전 변형은 모두 자동으로 바로잡습니다. 아무것도 저장하지 않습니다.
- 저장되지 않음
- 대기열 없음, 기다림 없음
- 회원가입 없음, 워터마크 없음
Base64를 붙여 넣으면 디코딩된 내용이 여기에 표시돼요.
사용 방법
Base64 붙여넣기
줄 바꿈이 있든, 패딩이 없든, URL 안전 형식이든, PEM 블록 안에 있든 모두 받으며, 바로잡은 내용을 하나하나 알려 드립니다.
원래 내용 확인
텍스트는 텍스트로 보여 드립니다. 바이너리는 PNG, PDF, ZIP처럼 바이트 자체로 식별해 올바른 확장자로 다운로드할 수 있게 해 드립니다.
복사 또는 저장
텍스트를 복사하거나 복원된 파일을 다운로드하세요.
디코딩하면 무엇이 나오나요
Base64에 담긴 것은 바이트이며, 이 페이지는 대체되는 문자 없이 올바른 UTF-8로 디코딩될 때만 텍스트로 보여 줍니다. 디코더가 엄격 모드로 작동하므로, UTF-8이 아닌 바이트 열은 화면 가득한 대체 문자가 아니라 아예 텍스트를 만들지 않습니다. 이는 의도된 것입니다. 물음표 마름모가 빽빽한 화면은 결과처럼 보이지만 결과가 아니기 때문입니다. 텍스트가 없으면 대신 바이트를 다운로드로 제공하며, 확장자는 앞부분 몇 바이트에서 직접 읽어 냅니다. PNG, JPEG, GIF, WebP, PDF, gzip, ZIP, RAR, 7z, 세 가지 웹 폰트 형식을 인식하며, ZIP은 안을 들여다봐서 .docx, .xlsx, .pptx, .epub을 일반 압축 파일과 구분합니다. 인식되지 않고 텍스트도 아닌 것은 .bin으로 나옵니다.
바로잡는 방식은 알아 둘 가치가 있습니다. 그중 하나는 규칙이 아니라 추측이기 때문입니다. 줄 바꿈 제거, PEM 머리글·바닥글 줄 제거, 빠진 패딩 추가는 모두 명확합니다. 원래 문자열일 수 있는 것이 정확히 하나뿐입니다. 공백은 그렇지 않습니다. 우연히 들어간 공백일 수도 있고, 전송 중 어딘가에서 URL이 공백으로 바꿔 버린 "+"일 수도 있습니다. 두 해석을 모두 시도하되 "+"를 먼저 시도하며, 먼저 디코딩되는 쪽을 보여 드립니다. 문자열이 어느 쪽으로도 디코딩된다면 어떤 의도였는지 알 방법이 없으므로, 믿기 전에 결과를 확인하세요. 두 문자 집합이 섞인 문자열, 즉 "-"나 "_"와 함께 "+"나 "/"가 있는 문자열은 아예 바로잡지 않습니다. 옳은 해석이 존재하지 않기 때문입니다.
다른 작업이 필요할 때
이 작업은 이미 내 컴퓨터가 할 수 있습니다. macOS와 Linux에서는 base64 -d, Windows에서는 certutil -decode, 어디서나 openssl base64 -d, 또는 Python 한 줄이면 됩니다. 모두 클립보드가 아니라 파일을 받으며, 웹 페이지를 거치지 않습니다. 지금 실제로 쓰이는 인증 정보라면 어떤 사이트가 무엇을 약속하든, 이 사이트를 포함해서, 그쪽이 더 좋은 습관입니다. 이 페이지의 주장은 사실이며, 그것을 확인하는 방법은 문장 자체가 아니라 페이지를 불러온 뒤 연결을 끊고도 디코더가 계속 작동하는지 보는 것입니다. 그리고 확인할 수 없는 곳에 이미 유효한 비밀 값을 붙여 넣었다면 교체하세요. 교체는 1분이면 끝나지만, 안전했는지 따지는 고민은 끝이 없습니다.
또 다른 한계는 크기입니다. 문자열은 텍스트로, 결과는 다시 바이트로 메모리에 올라가므로, 큰 이미지의 data URI는 탭 메모리를 몇 배로 차지합니다. 수백 MB 규모는 여기서 실패하지만, 명령줄 디코더는 스트리밍으로 아무렇지 않게 처리합니다. 데이터베이스 덤프의 한 열을 디코딩하거나 스타일시트에서 data URI를 모두 꺼내는 일도 이유는 다르지만 답은 같습니다. 그건 붙여넣기가 아니라 스크립트로 할 일입니다.
자주 묻는 질문
제 Base64가 어딘가에 저장되나요?
아니요. 아무것도 저장하지 않고, 로그도 남기지 않으며, 어떤 서버도 내용을 보지 않습니다. 네트워크를 끊어도 계속 작동합니다. 특히 이런 도구에서는 이것이 부가적인 장점이 아닙니다. 사람들이 온라인 인코더와 디코더에 붙여 넣는 것은 세션 토큰, API 키, Authorization 헤더, 고객 기록처럼 실제로 쓰이고 있는 값인 경우가 많습니다. 이를 어딘가로 전송하는 페이지에 붙여 넣는 것은 사이트가 삭제에 대해 무엇을 약속하든 곧 유출입니다.
정확히 복사했는데 잘못된 Base64라고 나와요
복사한 문자열을 망가뜨리는 흔한 원인은 네 가지이며, 여기서는 네 가지 모두 거부하지 않고 자동으로 바로잡습니다. 이메일 헤더, PEM 블록, MIME 줄 바꿈에서 생긴 줄 바꿈은 제거합니다. 빠진 = 패딩은 추가합니다. URL 안전 문자 집합(+와 / 대신 -와 _)은 감지해서 변환합니다. 그리고 공백은 두 가지로 모두 시도합니다. 우연히 들어간 공백으로도 보고, URL이 공백으로 바꿔 버린 + 문자로도 봅니다. Base64가 쿼리 문자열을 거칠 때마다 실제로 일어나는 일입니다. 바로잡은 내용은 결과에 하나하나 표시되므로, 문자열이 실제로 어떤 상태였는지 알 수 있습니다. 그래도 실패한다면 복사하는 과정에서 문자가 정말로 사라진 것이며, 페이지가 어느 부분인지 알려 드립니다.
JWT도 디코딩할 수 있나요?
각 부분을 디코딩할 수는 있지만, 그런 용도라면 JWT 디코더가 더 좋습니다. 세 부분을 나누고, JSON을 정렬하고, 타임스탬프를 실제 날짜로 바꾸고, 토큰이 만료되었는지 알려 줍니다. 실제로 쓰이는 세션 토큰을 어디서든 범용 디코더에 붙여 넣지 마세요. 이 사이트에서는 어느 쪽이든 저장되지 않지만, 대부분의 사이트는 그렇지 않습니다.
이미지나 PDF는 어떻게 되나요?
형식을 인식해 다운로드할 수 있게 해 드립니다. 파일 형식은 사용자가 알려 주는 정보가 아니라 PNG 시그니처, PDF 헤더, ZIP 표식처럼 디코딩된 바이트 자체로 식별하므로, 원래 파일 이름이 사라진 지 오래여도 다운로드 파일에는 올바른 확장자가 붙습니다. 이미지는 페이지에서 미리 볼 수 있습니다.
결과에 나오는 “Base64URL로 읽었어요”는 무슨 뜻인가요?
문자열이 URL 안전 문자 집합을 썼다는 뜻입니다. 이 집합에서는 -와 _가 +와 / 대신 쓰입니다. JWT, OAuth, URL에 담기는 모든 것이 쓰는 변형입니다. 두 문자 집합은 서로 다른 바이트로 디코딩되므로, 잘못 고르면 오류가 아니라 조용한 손상이 생깁니다. 그래서 짐작하지 않고 감지해서 알려 드립니다.
누군가 보낸 것을 안전하게 디코딩할 수 있나요?
디코딩 자체는 안전합니다. 아무것도 실행되지 않고, 아무것도 저장되지 않습니다. 하지만 나온 결과는 조심하세요. Base64는 악성 스크립트나 실행 파일을 메일 필터로부터 숨기는 흔한 방법이므로, 예상치 못한 곳에서 온 디코딩 파일은 예상치 못한 첨부 파일과 똑같이 다루세요.
용량 제한이 있나요?
고정된 용량 한도가 아니라 사용 가능한 메모리가 한계입니다. 큰 문자열도 문제없이 디코딩됩니다.
참고: 결과는 바이트이며, 바이트는 자신이 무엇인지 말해 주지 않습니다. 파일 형식은 데이터 앞부분의 매직 넘버로 추측하는데, 흔한 형식에는 정확하지만 나머지에 대해서는 아무 말도 하지 않습니다. 처음부터 올바르지 않았던 Base64는 오류가 아니라 알아볼 수 없는 내용으로 디코딩되므로, 결과가 제대로인지 확인하세요.
내 웹사이트에 이 도구 넣기
블로그, 수업 페이지, 도움말 글 어디에나 무료로 넣을 수 있습니다. 코드 한 줄만 붙여 넣으면 방문자가 페이지에서 바로 사용할 수 있습니다.