Base64를 비밀 보호 수단으로 쓰기
Base64는 되돌릴 수 있는 인코딩이지 암호화가 아닙니다. 값을 받은 사람은 누구나 디코딩할 수 있으므로 비밀번호, API 키, 쿠키, 토큰을 보호하지 못합니다.
Base64 인코더와 디코더 | UTF-8·Base64URL·Data URI
인코딩브라우저에서 실행(업로드 없음)
한도가 명확한 UTF-8 텍스트를 표준 Base64 또는 Base64URL로 인코딩하고, Base64·Base64URL·Base64 Data URI를 브라우저에서 엄격하게 디코딩합니다. 패딩과 남는 비트가 정규 형식인지 검증하고, 읽을 수 있는 UTF-8과 바이너리 바이트를 구분해 원본 바이트를 그대로 다운로드할 수 있습니다.
다음에 할 작업
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
작업 가이드
바이트를 손상하지 않고 Base64 API payload 디코딩하기
인코딩된 JSON 필드, Webhook metadata, 헤더, 쿠키, 로그를 반복 가능한 순서로 점검합니다. 디코딩 전에 알파벳과 패딩을 검증하고 바이너리 바이트를 보존하며 Base64를 암호화나 서명 검증과 구분합니다.
열기관련 도구파일 해시·체크섬 생성기
UTF-8 텍스트나 파일 원본 바이트를 해시하고 전체 체크섬을 로컬에서 비교합니다.
열기관련 도구JSON 포매터 | 원문을 보존해 보기 좋게 정리·압축
중복 키와 숫자 원문을 보존하며 엄격한 JSON을 로컬에서 정리하거나 압축합니다.
열기관련 도구JWT 디코더: 클레임과 만료 시간 확인
서명을 검증하지 않고 JWT 구조와 시간 클레임을 엄격하게 로컬 디코딩합니다.
열기이 도구 사용 방법
UTF-8 텍스트를 변환하려면 인코딩을, Base64·Base64URL·Base64 Data URI를 풀려면 디코딩을 선택합니다.
인코딩에서는 표준 또는 URL-safe를 고르고, 대상 프로토콜이 생략을 허용한다고 명시하지 않았다면 패딩을 유지합니다.
디코딩에서는 자동 감지를 유지하거나 API 계약을 검사할 때 특정 알파벳을 강제합니다.
값을 붙여 넣거나 텍스트 파일을 불러온 뒤, 큰 입력은 수동 모드에서 의도적으로 실행합니다.
바이트 수, 감지된 알파벳, 출력 유형, 공백·패딩·Data URI 알림을 확인합니다.
읽을 수 있는 텍스트와 Base64 출력은 복사하고, 바이너리 결과는 16진수 미리보기를 원본으로 오해하지 말고 정확한 바이트를 다운로드합니다.
이 도구를 써야 할 때
UTF-8 API 값 준비
다국어 문자열을 문서화된 텍스트 전용 API 필드에 넣기 전에 인코딩하고 정확한 바이트·문자 수를 비교합니다.
인코딩된 API payload 점검
복사한 JSON, Webhook, 로그 필드를 디코딩하고 포맷 또는 마스킹 전에 읽을 수 있는 텍스트인지 확인합니다.
Base64URL 프로토콜 필드 디버깅
패딩 없는 Base64URL 구간과 알파벳 조건을 검사하되 JWT 서명까지 검증했다고 오해하지 않습니다.
Base64 Data URI 점검
data:text/plain;base64,... 또는 다른 유효 Base64 Data URI를 선언된 미디어 타입과 함께 디코딩합니다.
바이너리 payload 바이트 복구
유효하지 않은 UTF-8이나 바이너리로 선언된 내용을 구분하고 짧은 16진수 미리보기를 검토한 뒤 전체 바이트를 저장합니다.
흔한 실수
표준 알파벳과 URL-safe 알파벳 섞기
표준 Base64는 +와 /를, Base64URL은 -와 _를 사용합니다. 검증 없이 나중에 문자를 치환하지 말고 수신 프로토콜이 요구하는 알파벳을 먼저 선택해야 합니다.
모든 패딩 모양이 유효하다고 가정하기
패딩은 프로토콜이 허용할 때만 생략할 수 있습니다. 잘못 놓인 = 하나나 0이 아닌 남는 비트 때문에 느슨한 디코더에서는 되지만 엄격한 시스템에서는 거절될 수 있습니다.
바이너리 바이트를 UTF-8 텍스트로 강제 변환하기
디코딩된 바이트가 항상 텍스트인 것은 아닙니다. 이미지, 압축 데이터, 암호화 데이터, 비 UTF-8 파일은 대체문자가 섞인 화면 텍스트가 아니라 원본 바이트로 다운로드해야 합니다.
크기를 확인하지 않고 큰 payload 넣기
Base64는 JSON, HTML, 전송 오버헤드 전에도 크기가 약 3분의 1 늘어납니다. 이 도구는 브라우저 작업을 제한하기 위해 원본 또는 디코딩 결과를 1,048,576바이트로 제한합니다.
예시
다국어 UTF-8 텍스트 인코딩
정확한 UTF-8 바이트를 표준 알파벳과 정규 패딩으로 인코딩합니다.
입력
Hello, 안녕하세요, 👋출력
SGVsbG8sIOyViOuFle2VmOyEuOyalCwg8J+Riw==패딩 없는 Base64URL payload 디코딩
패딩이 생략된 Base64URL 값을 자동 감지하고 읽을 수 있는 UTF-8 JSON 텍스트로 디코딩합니다.
입력
eyJzdGF0dXMiOiJvayIsImVtb2ppIjoi8J-nqiJ9출력
{"status":"ok","emoji":"🧪"}엄격한 Base64 검증 방식
RFC 4648 Base64는 입력 3바이트를 출력 가능한 4문자로 매핑합니다. 마지막 묶음에는 = 패딩 한두 개가 필요할 수 있어 결과 크기는 보통 약 33% 증가합니다.
Base64URL은 같은 6비트 값을 쓰되 +와 /를 -와 _로 바꿉니다. 패딩 생략은 별도의 프로토콜 선택이며 URL-safe라는 이유만으로 모든 무패딩 또는 혼합 알파벳 문자열이 유효해지는 것은 아닙니다.
엄격한 디코딩은 알파벳, 길이, 패딩 위치, 사용하지 않는 마지막 비트를 확인한 뒤 바이트를 다시 인코딩해 정규 왕복 결과인지 검증합니다.
줄바꿈된 payload를 위해 ASCII 스페이스·탭·개행은 제거하고 개수를 알립니다. 다른 유니코드 공백과 문장부호는 조용히 버리지 않고 거절합니다.
디코딩된 바이트는 대체문자 없이 UTF-8 해석에 성공하고 위험한 제어 바이트가 없을 때만 텍스트로 표시합니다. 그 외에는 제한된 16진수 미리보기와 원본 바이트 다운로드를 제공합니다.
자주 묻는 질문
Base64가 비밀 정보를 보호하나요?
아닙니다. Base64는 바이트를 출력 가능한 ASCII 문자로 매핑할 뿐입니다. 기밀성에는 인증된 암호화를, 전송 보호에는 HTTPS를 사용하고, 읽기 어려워 보인다는 이유로 값을 공개하면 안 됩니다.
Base64와 Base64URL은 어떻게 구분하나요?
표준 Base64는 +와 /를 사용하고 보통 = 패딩을 포함합니다. Base64URL은 -와 _를 사용하며 패딩을 생략하는 경우가 많습니다. 자동 감지는 각 알파벳 전용 문자를 확인하고, 공통 문자만 있으면 원래 알파벳을 구분할 수 없다고 알립니다.
= 패딩이 없는 Base64도 디코딩할 수 있나요?
정규 패딩 입력과 패딩 없는 입력을 모두 받을 수 있습니다. 필요한 패딩만 계산해 복원하며, 잘못된 위치의 패딩, 불가능한 길이, 섞인 알파벳, 0이 아닌 남는 비트는 거절합니다.
디코딩 결과가 바이너리이면 어떻게 되나요?
바이트가 읽을 수 있는 유효한 UTF-8이 아니면 출력에는 최대 256바이트의 16진수 미리보기만 표시합니다. 다운로드에는 모든 바이트가 유지되며, Data URI가 있으면 선언된 미디어 타입을, 없으면 application/octet-stream을 사용합니다.
Base64 Data URI도 디코딩할 수 있나요?
헤더가 ;base64로 끝나고 제한된 유효 미디어 타입을 가질 때 지원합니다. 헤더와 payload를 분리해 검증하고 선언된 미디어 타입을 표시하며 다운로드에도 적용합니다. 퍼센트 인코딩 또는 Base64가 아닌 Data URI는 별도로 처리해야 합니다.
크기와 파일 형식 제한은 무엇인가요?
인코딩은 UTF-8 기준 최대 1,048,576바이트를 받습니다. 디코딩은 최대 1,048,576바이트를 만드는 정규 Base64 payload와 제한된 ASCII 공백·Data URI 헤더를 받습니다. 인코딩은 텍스트 중심이며 임의 바이너리 파일 인코딩은 파일 전용 흐름에서 처리해야 합니다.
이 도구를 검증한 방법
관리 및 검수 SimpleWebUtils검토일
검증 방법: 가이드 입력을 바꾸지 않은 채 Base64 인코더와 디코더에서 다음 예제를 재현했습니다: “Base64 API metadata 필드 하나 디코딩”. 정상 절차는 “알파벳 선택 또는 자동 감지”, “형식에 맞는 다음 도구 사용”; 경계 검토는 “응답 전체를 디코딩”, “대체문자를 원본 데이터로 취급”로 분리해 결과를 확정했습니다.
기대 결과: Base64 필드는 payment.succeeded JSON 객체로 정확히 복원됐고, 잘못된 알파벳이나 패딩은 일부 JSON처럼 보이는 결과가 아니라 명시적인 오류로 남았습니다.
공식 출처와 표준
- RFC 4648: Base-N EncodingsRFC Editor / IETF
관련 작업 가이드
도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
작업 가이드
바이트를 손상하지 않고 Base64 API payload 디코딩하기
인코딩된 JSON 필드, Webhook metadata, 헤더, 쿠키, 로그를 반복 가능한 순서로 점검합니다. 디코딩 전에 알파벳과 패딩을 검증하고 바이너리 바이트를 보존하며 Base64를 암호화나 서명 검증과 구분합니다.
작업 가이드반복 키 XOR를 보안이 아닌 학습에 사용하기
암호 학습 워크벤치에서 XOR 바이트 원리를 눈에 보이게 확인합니다. 알려진 벡터를 재현하고 Hex와 Base64를 비교한 뒤 같은 키로 되돌리면서, 실제 비밀 보호라고 표현하면 안 되는 이유까지 기록합니다.
작업 가이드데이터 전달용 바이너리-텍스트 인코딩 선택하고 검증하기
API, 데이터베이스 필드, DNS 레이블, 이메일 본문, 설정 파일, 레거시 전송 규칙이 Base32·Base58·Base62·Base85·16진수·엔티티·Punycode·quoted-printable·UTF-16·UUEncode를 요구하지만 변형을 충분히 설명하지 않을 때 사용하는 흐름입니다.
작업 가이드SHA-256으로 파일 체크섬 확인하기
로컬 파일 모드와 명시적인 체크섬 비교 기능으로 릴리스 파일, 백업, 설치 프로그램의 바이트 동일성을 확인합니다. 일치는 배포자의 신뢰나 악성 코드 부재를 인증하지 않습니다.
작업 가이드JWT를 안전하게 디코딩하기
JWT를 안전하게 디코딩하기가 필요할 때 원본 데이터를 정리하고 설정을 확인한 뒤 복사하거나 저장할 수 있는 결과로 마무리하는 흐름입니다.
작업 가이드JWT 만료와 not-before 타임스탬프 확인하기
요청이 nbf 전인지, exp와 같거나 이후인지, 선언된 token 구간 안인지 판단하면서 clock skew 정책을 기록하고 공유 증거에서는 원본 token을 제거하는 절차입니다.
관련 도구
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
파일 해시·체크섬 생성기
UTF-8 텍스트나 파일 원본 바이트를 해시하고 전체 체크섬을 로컬에서 비교합니다.
인코딩
JSON 포매터 | 원문을 보존해 보기 좋게 정리·압축
중복 키와 숫자 원문을 보존하며 엄격한 JSON을 로컬에서 정리하거나 압축합니다.
포맷팅
JWT 디코더: 클레임과 만료 시간 확인
서명을 검증하지 않고 JWT 구조와 시간 클레임을 엄격하게 로컬 디코딩합니다.
보안
QR 코드 생성기 | 정확한 PNG·SVG와 스캔 안전 설정
입력한 정확한 텍스트나 준비된 URL·Wi-Fi·이메일·전화·SMS·vCard payload를 PNG 또는 SVG QR로 만듭니다.
QR코드
URL 인코더·디코더 | 정확한 퍼센트 인코딩과 + 규칙
정확한 URL 컴포넌트, 전체 URL, 폼 값을 브라우저에서 인코딩·디코딩합니다.
인코딩