Base64 인코더 / 디코더
Base64, Base64URL, Base32, 16진수를 인코딩하고 디코딩하세요 — 텍스트는 입력하는 즉시, 파일은 드래그 앤 드롭으로 — 어깨만 으쓱하는 대신, 속하지 않은 첫 번째 문자의 정확한 위치를 알려줄 만큼 엄격한 디코더와 함께. 모든 작업은 브라우저에서 실행됩니다. 사람들이 디코딩하는 문자열은 너무나 자주 토큰과 비밀이기 때문에, 그것을 서버로 보내거나 기록이 남는 AI 채팅에 붙여넣는 일은 디코더가 절대 요구해서는 안 되는 일입니다.
파일
이 상자 안 아무 곳에나 파일을 놓으면 위에서 선택한 형식으로 인코딩되어, 인코딩된 텍스트와 바로 사용할 수 있는 data URL을 얻을 수 있습니다. 또는 인코딩된 텍스트를 여기에 붙여넣고 디코딩된 바이트를 파일로 다운로드하세요.
네 가지 알파벳, 하나의 일
네 형식 모두 같은 일을 합니다 — 임의의 바이트를 안전하고 인쇄 가능한 문자만으로 쓰는 것 — 다만 상대가 다릅니다. 표준 Base64는 이메일 첨부, 설정 파일, 그리고 수많은 API의 기본값입니다. Base64URL은 URL을 깨뜨리는 두 문자(+와 /)를 -와 _로 바꾸고 패딩을 없앤 것으로, 모든 JSON Web Token 내부에 들어 있는 알파벳입니다 — JWT 디코더로 하나를 디코딩하면 세 세그먼트가 모두 이 형식입니다. Base32는 더 작고 대소문자를 구분하지 않는 알파벳을 사용해 소리 내어 읽고 다시 입력해도 살아남기 때문에, TOTP 인증 비밀은 이 형식으로 발급됩니다. Hex는 크기를 두 배로 만드는 대신 완전한 투명성을 삽니다. 1바이트, 2문자, 숨는 것은 아무것도 없습니다 — 해시의 형식으로, 해시 생성기가 만들고 해시 식별기가 알아봅니다.
이 엄격함은 의도된 것이며, 디코더와 디버깅 도구의 차이가 바로 그것입니다. atob() 같은 브라우저 내장 함수는 위치 4에 오타가 있는 문자열에 대해서도, 아예 Base64가 아닌 문자열에 대해서도, 하나의 일반적인 오류만 던집니다. 이 디코더는 문자 단위로 검증하고 처음 실패하는 위치를 보고합니다 — JSON에서 끌려 들어온 따옴표, URL 안전 알파벳이 있어야 할 자리에 있는 +, 중간에 걸린 패딩, 또는 남는 비트가 0이 아닌 마지막 문자(인코딩 이후 문자열이 편집되었다는 뜻)입니다. "디코딩이 안 돼요"라는 미스터리의 90%는 누군가 그 한 위치를 가리키는 순간 눈에 보이게 됩니다. 그리고 이 작업에는 자격 증명이 얽히는 일이 너무나 많기 때문에 — Kubernetes 비밀은 Base64입니다(인코딩이지, 결코 암호화가 아닙니다), 토큰 페이로드, 설정 파일 속 키 — 변환 전체가 로컬에서 이루어지며, .env 검증기와 같은 규칙을 따릅니다. 민감한 입력은 절대 전송되지 않습니다. 짝을 이루는 글 Base64는 암호화가 아닙니다에서 이 구분이 왜 중요한지 더 길게 설명합니다.
자주 묻는 질문
Base64는 암호화의 한 형태인가요?
아니요. Base64는 인코딩입니다 — 키도 비밀성도 없는, 되돌릴 수 있는 옷 갈아입기에 불과합니다. Base64 문자열을 본 사람은 누구나 즉시 디코딩할 수 있으므로, "API 키가 설정에 Base64로 인코딩되어 있다"는 말은 API 키가 사실상 평문으로 설정에 있다는 뜻입니다. Base64는 암호화가 아닙니다 글에서는 인코딩, 암호화, 해싱의 차이와, 각각을 혼동했을 때 생기는 실수를 풀어 설명합니다.
이 디코더는 왜 오류의 정확한 위치를 알려주나요?
위치 없는 "잘못된 문자"는 일반적인 디코더가 당신의 오후를 낭비하게 만드는 방식이기 때문입니다. 붙여넣은 문자열은 보통 세 가지 중 하나의 이유로 실패합니다. 주변 텍스트에서 딸려 들어온 엉뚱한 문자(따옴표, 쉼표, 로그의 한 줄), 잘못된 알파벳(URL 안전 문자열을 표준 디코더에 넣은 경우), 또는 잘린 복사입니다. 여기서는 처음 문제를 일으킨 문자와 그 인덱스가 제시되므로, 바로 그 지점을 보고 세 가지 중 무엇이 일어났는지 알 수 있습니다.
Base64와 Base64URL의 차이는 무엇인가요?
알파벳입니다. 표준 Base64는 +와 /를 사용하는데, 이들은 URL에서 구조적인 문자이기 때문에 URL 안전 Base64는 그것들을 -와 _로 바꾸고 보통 = 패딩을 없앱니다. 모든 JWT 안에 들어 있는 것이 바로 이 변형입니다. 한 변형을 다른 쪽 디코더에 넣는 것은 첫 번째 +나 /의 위치에서 디코딩이 실패하는 가장 흔한 원인입니다 — 이 도구는 모드를 분리해 두었기 때문에, 오류 메시지가 바로 그것이 일어났다고 알려줄 수 있습니다.
여기서 토큰이나 비밀을 디코딩해도 안전한가요?
네 — 변환은 사용자의 브라우저, 이 페이지 안에서 실행되며, 붙여넣은 내용은 전송되거나 저장되지 않습니다. 사람들이 디코딩하는 것이 너무나 자주 자격 증명이기 때문에 이것이 중요합니다. 설정 파일 속 Base64 덩어리, Kubernetes 비밀(그것은 Base64이지 암호화가 아닙니다 — 위 질문 참조), 토큰 페이로드가 그렇습니다. 같은 문자열을 AI 채팅에 붙여넣으면 기록이 남는 제3자 시스템으로 복사본이 전송됩니다. 채팅봇에게 비밀을 맡기지 마세요를 참조하세요.
파일이 "유효한 UTF-8이 아님"으로 디코딩된 이유는 무엇인가요?
그것이 바이너리이기 때문입니다 — 이미지, 압축 파일, 컴파일된 무언가 — 그리고 바이너리는 텍스트가 아닙니다. 텍스트 디코더는 깨진 문자를 건네는 대신 거부합니다. 텍스트 상자 아래의 파일 섹션을 사용하세요. Base64를 거기에 붙여넣으면 바이트가 온전한 재구성 파일을 다운로드할 수 있습니다.