> base64 디코더 | paste | decode <

Base64 문자열을 위의 입력 영역에 붙여넣으세요 — 자동 디코딩(기본 활성화)이 입력과 동시에 실행됩니다. 디코딩된 텍스트는 출력 영역에 즉시 나타납니다. [DECODE] 버튼을 직접 클릭하거나 Ctrl/Cmd + Enter를 사용할 수도 있습니다. 모든 처리는 브라우저에서 로컬로 이루어지며 서버로 전송되지 않으므로 JWT 토큰, OAuth state 또는 기밀 데이터를 붙여넣어도 안전합니다.

모든 변형. 디코더가 자동으로 감지하고 수용합니다:
• 표준 Base64 (RFC 4648) — 알파벳 A-Z a-z 0-9 + /, = 패딩.
• URL-safe Base64 (RFC 4648 §5) — + 및 / 대신 -와 _ 사용. JWT, OAuth, Google API, AWS S3 presigned URL에서 사용.
• 패딩 없는 Base64 — 끝의 = 문자가 생략됨. JWT에서 흔하며, 디코더가 패딩을 자동으로 추가해야 합니다.
• 공백 허용 — Base64 문자열 내의 줄바꿈, 탭, 공백은 디코딩 전에 제거됩니다(이메일 본문의 76열 MIME 래핑 처리).

감지된 형식은 버튼 아래 배지로 표시되어 입력이 어떤 변형으로 분류되었는지 알 수 있습니다.

디코딩 실패의 주요 원인은 다음 5가지입니다:

1. 입력이 실제로 Base64가 아닙니다. 많은 사람이 Base64를 16진수, Base32 또는 URL 인코딩과 혼동합니다. Base64는 A-Z a-z 0-9 + / =(URL-safe는 - _)만 사용합니다. 문자열에 %20이 있으면 퍼센트 인코딩이고, 전부 0-9 a-f면 16진수일 가능성이 높습니다.

2. 잘림. Base64 길이는 패딩 후 4의 배수여야 합니다. 복사-붙여넣기로 끝의 ==가 누락되면 "잘못된 길이" 오류가 발생합니다. 이 디코더는 자동으로 패딩을 추가하지만, 심하게 잘린 문자열은 여전히 실패합니다.

3. URL-safe와 표준 혼합. +/-_이 모두 존재하면 문자열이 모호하고 손상되었을 가능성이 높습니다. 한 가지 변형만 사용해야 합니다.

4. 이중 인코딩. 문자열이 Base64로 두 번 인코딩된 경우가 있습니다. 한 번 디코딩하면 그 자체가 또 Base64인 이상한 문자가 나옵니다. 다시 디코딩하면 최종 텍스트를 얻을 수 있습니다.

5. 원본 바이트가 UTF-8이 아님. Base64는 바이트로 디코딩됩니다. 원본 바이트가 유효한 UTF-8이 아닌 경우(예: 암호화된 blob이나 PNG 같은 원시 바이너리), 디코딩된 출력은 mojibake처럼 보입니다. 이는 예상된 동작 — Base64-파일 도구를 사용하세요.

JWT는 점으로 구분된 세 부분으로 구성됩니다: header.payload.signature. 세 부분 모두 패딩 없는 URL-safe Base64입니다. payload를 검사하려면:

1. 가운데 세그먼트(두 점 사이)를 복사합니다.
2. 위의 디코더에 붙여넣습니다. 자동 디코딩이 URL-safe 알파벳을 처리하고 누락된 패딩을 추가합니다.
3. iss, sub, exp, iat 같은 클레임이 포함된 JSON payload를 얻습니다.

서명(세 번째 세그먼트)은 바이너리 HMAC 또는 RSA 출력으로, 텍스트로 디코딩하면 이상한 문자가 나옵니다. 이는 예상된 동작입니다. 서명 검증을 포함한 완전한 JWT 인스펙터는 전용 JWT 디코더를 사용하세요.

보안 참고: JWT 디코딩은 검증이 아닙니다. 누구나 JWT payload를 읽을 수 있습니다 — 이는 설계상 그렇습니다. 서명은 토큰이 발행자에게서 왔음을 증명하며, 발행자의 공개 키나 공유 시크릿으로 별도로 검증됩니다.

예 — 모든 주요 플랫폼에 Base64 디코더가 기본 탑재되어 있습니다:

macOS / Linux (bash/zsh):
echo 'SGVsbG8=' | base64 -d — Hello 출력. macOS에서 -d가 작동하지 않으면 -D 사용. URL-safe 입력의 경우 먼저 tr '_-' '/+'로 파이프하세요.

Windows PowerShell:
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8='))

Python:
import base64
base64.b64decode('SGVsbG8=').decode('utf-8') # Hello
base64.urlsafe_b64decode(s + '===').decode() # URL-safe 자동 패딩

Node.js:
Buffer.from('SGVsbG8=', 'base64').toString('utf-8')

브라우저 DevTools:
atob('SGVsbG8=') — 모든 콘솔에서 작동. UTF-8 문자열은 new TextDecoder().decode(Uint8Array.from(atob(s), c => c.charCodeAt(0)))로 래핑하세요.

PHP: base64_decode('SGVsbG8=')
Ruby: Base64.decode64('SGVsbG8=')
Go: base64.StdEncoding.DecodeString("SGVsbG8=")

예 — 이 디코더는 브라우저를 벗어나는 것이 없으므로 서버 측 도구보다 안전합니다. 디코딩은 네이티브 atob() 및 TextDecoder API를 통해 기기의 JavaScript에서 전적으로 수행됩니다. 네트워크 호출, 업로드, 로깅, 입력 내용에 대한 분석이 없습니다. 디코딩하면서 브라우저 DevTools의 네트워크 탭을 열어 직접 확인할 수 있습니다 — 요청이 0인 것을 볼 수 있습니다.

그럼에도 Base64는 암호화가 아니라 단지 인코딩입니다. Base64 문자열을 가진 누구나 디코딩할 수 있습니다. 따라서 이 도구는 안전하지만 다음을 지켜야 합니다:
• 만료되지 않은 디코딩된 JWT의 스크린샷을 공유하지 마세요.
• 어디든(로그, 스크린샷, 공유 채팅) 유출된 자격 증명은 로테이션하세요.
• 디코딩된 OAuth state, CSRF 토큰, 세션 ID는 무효화될 때까지 비밀로 취급하세요.

Base64 문자열 자체가 민감한 기업/규제 환경에서는 이 페이지를 오프라인 저장(Cmd/Ctrl + S)할 수 있습니다 — 디코딩 로직은 순수 JavaScript이므로 한 번 로드 후 완전히 격리되어 작동합니다.

Data URI는 data:[<mediatype>][;base64],<data> 구문을 따릅니다. payload만 디코딩하려면:

1. 쉼표를 찾으세요. 그 앞은 메타데이터(data:image/png;base64), 뒤는 Base64로 인코딩된 파일입니다.
2. 쉼표 뒤 부분만 이 디코더에 복사하세요.
3. 바이너리 콘텐츠(PNG, JPG, PDF)의 경우 디코딩된 출력은 원시 바이트이며, 텍스트 렌더링은 mojibake를 보여줍니다. 이는 예상된 것입니다.
4. Data URI 이미지를 보려면 전체 data:... URI를 브라우저 주소창에 붙여넣으세요 — 브라우저가 직접 디코딩하고 렌더링합니다.
5. 이미지 파일로 저장하려면 전용 Base64 → 이미지 도구를 사용하세요. 전체 Data URI를 처리하고 PNG/JPG/WebP로 다운로드합니다.

Data URI는 다음에서 흔히 발견됩니다: CSS background-image 규칙, 인라인 SVG 아이콘, 이메일 서명 이미지, JSON API 응답에 인코딩된 PDF 첨부, Electron/VS Code 확장 아이콘 번들.

인코딩은 임의의 바이너리 또는 텍스트 데이터를 인쇄 가능한 문자만 사용하는 ASCII 문자열로 만듭니다 — 텍스트 전용 채널(이메일, URL, JSON)에서의 전송에 안전합니다. 디코딩은 그 반대입니다: ASCII Base64 문자열이 원본 바이트가 됩니다.

주요 속성:
• 무손실 왕복: 모든 바이트 입력에 대해 decode(encode(x)) === x. 데이터는 결코 손실되지 않습니다.
• 암호화가 아님: Base64는 비밀성을 전혀 제공하지 않습니다. 누구나 디코딩할 수 있습니다.
• 크기 오버헤드: 인코딩된 출력은 입력보다 약 33% 큽니다(입력 3바이트당 출력 4바이트).
• 사용 사례: JWT 토큰, MIME 이메일 첨부, HTTP Basic Auth 헤더, OAuth 코드, S3 presigned URL, HTML/CSS 인라인 이미지.

이 페이지는 디코딩에 전념합니다. 반대 방향(텍스트/파일 → Base64)이 필요하면 홈페이지의 Base64 인코더 또는 이미지 파일용 이미지 → Base64 변환기를 사용하세요.

예, 브라우저 메모리 한도 내에서 가능합니다. 디코더는 무제한 입력 길이를 수용합니다 — 최신 노트북에서 50MB Base64 문자열(~37MB 디코딩됨)로 테스트했습니다. 성능:

• < 100KB: 즉시, UI 지연 없음.
• 1 – 10MB: CPU에 따라 디코딩이 ~50-500ms 소요.
• 10 – 100MB: atob가 동기식이므로 브라우저가 잠시(2-10초) 멈출 수 있습니다. 먼저 auto-decode를 비활성화하고 [DECODE]를 수동으로 클릭하세요.
• > 100MB: 브라우저 메모리 한도에 도달합니다. 기가바이트 규모의 Base64 파일은 명령줄 도구(base64 -d)를 사용하세요.

디코딩된 콘텐츠가 바이너리 파일(PNG, PDF, ZIP)이면 텍스트 출력 영역은 mojibake를 보여줍니다. 디코딩된 바이트를 파일로 다운로드하려면 Base64 → 이미지 도구(이미지 처리) 또는 명령줄 접근 방식을 사용하세요: echo '<base64>' | base64 -d > output.bin.

예. 페이지가 한 번 로드되면 모든 디코딩이 클라이언트 측 JavaScript에서 이루어집니다 — 네트워크가 필요 없습니다. 완전히 오프라인으로 만들려면:

1. 페이지 저장: Ctrl+S(Windows/Linux) 또는 Cmd+S(macOS)를 누르고 "웹페이지, 전체"로 저장합니다. 디코더는 저장된 HTML에서 작동합니다.
2. PWA로 설치(지원되는 경우): 일부 브라우저는 base64.sh에 대해 "이 앱 설치"를 제공합니다 — 오프라인 액세스가 가능한 런처를 제공합니다.
3. DevTools에서 사용: 네이티브 atob() 함수는 이 페이지 없이도 모든 브라우저 콘솔에서 작동합니다. 빠른 디코딩: atob('SGVsbG8=').

오프라인 작동은 다음에 유용합니다: 에어갭 보안 연구, 침투 테스트 랩, 엄격한 데이터 유출 방지 규칙이 있는 기업 환경, 인터넷이 없는 비행기/기차.