인코더·디코더
텍스트를 URL 인코딩과 Base64로 변환하고, 디코딩할 때는 형식을 자동으로 감지합니다.
변환 결과
텍스트를 입력하면 결과가 여기에 표시됩니다.
이 인코더·디코더는 무슨 일을 하나요?
위에 텍스트를 입력하거나 붙여넣고 인코딩 또는 디코딩을 고르면 변환 결과가 즉시 나타납니다. 서버로 전송되는 것은 아무것도 없습니다. 인코딩 모드에서는 URL 인코딩, URL 컴포넌트 인코딩, Base64 세 가지 결과를 한 번에 보여 줍니다. 디코딩 모드에서는 형식을 자동으로 시도해, 의미 있는 결과가 나오는 것만 골라 표시합니다. 쿼리 문자열을 이스케이프하거나 토큰을 디코딩하려고 브라우저 콘솔과 낯선 웹사이트 사이를 오가던 게 번거로워서 만들었습니다. 브라우저가 이미 할 수 있는 일이니까요.
URL에는 왜 인코딩이 필요한가요?
URL에는 사용할 수 있는 문자가 정해져 있어서, 그 밖의 문자는 반드시 이스케이프해야 하기 때문입니다. 공백, 앰퍼샌드(&), 물음표, 슬래시, 한글 같은 비영문 글자를 그대로 넣으면 URL의 의미가 달라지거나 아예 깨질 수 있습니다. 인코딩은 이런 문자를 % 시퀀스로 바꿔 줍니다. 예를 들어 공백은 %20이 됩니다. 그래야 주소를 복사하고, 링크로 걸고, 서버가 해석해도 원래 값이 그대로 유지됩니다.
그대로 둘 수 있는 문자는 많지 않습니다. URL 문법을 규정한 RFC 3986은 영문자 A–Z a–z, 숫자 0–9, 그리고 - . _ ~만 ’비예약(unreserved) 문자’로 정해 두었고, 나머지는 모두 % 삼중자로 바뀝니다. 한 바이트가 퍼센트 기호 + 16진수 두 자리가 되므로 ASCII 한 글자는 세 글자로 늘고, 비ASCII 문자는 UTF-8로 먼저 변환되기 때문에 한글 한 글자는 3바이트라 아홉 글자가 됩니다. 예를 들어 ’가’는 %EA%B0%80이 됩니다.
이 작업에 함수가 둘인 데에는 이유가 있습니다. encodeURI는 URL 전체를 대상으로 하므로 :, /, ?, # 같은 구조 문자는 건드리지 않습니다. 반면 encodeURIComponent는 URL 안에 끼워 넣을 하나의 조각, 즉 검색어나 쿼리 값 하나를 위한 것이라 이런 구조 문자까지 이스케이프합니다. 기준은 간단합니다. 링크 전체를 인코딩하면 앞엣것, 쿼리 문자열 안에 들어갈 값 하나를 인코딩하면 뒤엣것입니다. MDN에 정확한 이스케이프 집합이 정리돼 있습니다. encodeURIComponent는 - _ . ! ~ * ' ( )만 남기고, encodeURI는 여기에 더해 구조 문자 ; , / ? : @ & = + $ #까지 그대로 둡니다.
Base64는 무엇이고 언제 쓰나요?
Base64는 임의의 텍스트나 이진 데이터를 알파벳·숫자·+·/로만 이뤄진 안전한 문자 집합으로 바꾸는 방식입니다. 일반 텍스트만 받는 통로에 더 복잡한 데이터를 실어 보내야 할 때 씁니다. 작은 이미지를 data: URI로 HTML이나 CSS에 직접 넣거나, 인증 정보를 basic-auth 헤더에 담거나, 데이터 덩어리를 깨지지 않게 JSON에 끼워 넣을 때가 대표적입니다. 대신 데이터 크기가 보통 3분의 1 정도 늘어나는데, 이것이 안전을 얻는 대가입니다. 이 수치는 어림짐작이 아니라 정확한 값입니다. RFC 4648은 Base64를 3바이트(24비트)마다 65자 알파벳(A–Z, a–z, 0–9, +, /, 그리고 패딩용 =)에서 고른 4문자로 묶는 방식으로 정의하며, 이는 정확히 4/3, 즉 약 +33%의 크기 증가입니다. 한 가지 실무적인 점은, 브라우저의 btoa가 코드포인트 256 미만 문자만 받기 때문에 이 도구는 텍스트를 먼저 UTF-8로 변환한 뒤 인코딩한다는 것입니다. 그래서 이모지나 비라틴 문자도 깨지지 않고 왕복되며, 날것의 btoa라면 거부했을 입력도 여기서는 처리됩니다(MDN).
한 가지 분명히 할 점은, Base64는 암호화가 아니라는 것입니다. 누구나 되돌릴 수 있고, 이 도구도 한 번의 클릭으로 디코딩합니다. 그러니 비밀번호나 비밀 값을 감추는 수단으로는 절대 쓰지 마세요.
세 가지 형식 한눈에 비교
| 형식 | 정의 표준 | 출력 문자 집합 | 크기 영향 | 주로 쓰는 곳 |
|---|---|---|---|---|
URL 인코딩 (encodeURI) |
RFC 3986 | %XX 삼중자, 구조 문자는 유지 |
이스케이프된 문자마다 1 → 3자 | URL 전체 이스케이프 |
URL 컴포넌트 (encodeURIComponent) |
RFC 3986 | %XX 삼중자, 구조 문자까지 이스케이프 |
이스케이프된 문자마다 1 → 3자 | 쿼리·경로 값 하나 |
Base64 (btoa) |
RFC 4648 | A–Z a–z 0–9 + / = (65자) |
약 +33% (3바이트 → 4문자) | 이진 데이터를 텍스트 채널로 전송 |
Base64의 증가율이 내용에 상관없이 고정인 이유는 표준 문서에 그대로 나와 있습니다.
“The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters.”
— RFC 4648, §4
디코딩 자동 감지는 어떻게 동작하나요?
디코딩 모드에서는 입력을 URL 디코딩, URL 컴포넌트 디코딩, Base64 디코딩에 차례로 통과시킨 뒤, 실제로 텍스트가 바뀌거나 Base64로 성공한 시도만 보여 줍니다. 그래서 %로 이스케이프된 문자열은 URL 결과가, Base64 덩어리는 디코딩된 텍스트가 드러납니다. 자주 쓰며 얻은 팁 몇 가지를 덧붙입니다. 쿼리 값을 만들 때는 URL 컴포넌트 인코딩을 쓰고, Base64는 보호가 아니라 전송을 위한 것임을 기억하세요. 모든 변환이 브라우저 안에서만 이뤄지므로, 토큰이나 비공개 조각도 밖으로 새어 나갈 걱정 없이 안심하고 붙여넣을 수 있습니다.