Skip to content

URL 인코더 · 디코더 (URL Encoder & Decoder)

URL을 실시간 인코딩·디코딩하고 내장 파서로 구조를 분석합니다. encodeURI와 encodeURIComponent 모드를 온라인에서 지원하며 데이터는 브라우저를 떠나지 않습니다.

트래킹 없음 브라우저 실행 무료
디코딩된 값
인코딩된 값
RFC 3986 준수, encodeURI/encodeURIComponent 정확성, UTF-8 인코딩 정확성에 대해 검토되었습니다 — Go Tools 엔지니어링 팀 · Apr 7, 2026

URL 인코딩(퍼센트 인코딩)이란 무엇인가요?

URL 인코딩은 정식으로 퍼센트 인코딩이라고 부르며, 허용되지 않거나 특별한 의미를 가진 문자를 URI(Uniform Resource Identifier)에서 표현하기 위해 RFC 3986에 정의된 방식입니다. 안전하지 않은 각 바이트를 퍼센트 기호(%) 뒤에 16진수 두 자리를 붙인 형태로 변환합니다. 예를 들어 공백은 %20, 앰퍼샌드는 %26이 되고, 한자 中은 UTF-8 바이트 3개가 각각 퍼센트 인코딩되어 %E4%B8%AD가 됩니다.

URL은 ASCII 문자 집합의 일부만 포함할 수 있습니다. 알파벳, 숫자, 소수의 기호(-, _, ., ~)는 'unreserved'로 간주되어 그대로 나타날 수 있습니다. 공백, 구두점, 유니코드 전 범위를 포함한 나머지 문자는 URL에서 안전하게 전송되도록 퍼센트 인코딩되어야 합니다. ?, &, =, # 같은 reserved 문자는 URL 구문에서 구조적 구분자 역할을 하므로 구분자가 아니라 데이터로 사용할 때는 역시 인코딩해야 합니다.

퍼센트 인코딩은 웹 곳곳에서 필수적입니다. 브라우저는 폼 제출을 인코딩하고, API는 인코딩된 쿼리 파라미터를 요구하며, OAuth 흐름은 올바르게 인코딩된 리다이렉트 URI에 의존하고, 국제화 도메인 이름은 비 ASCII 문자 인코딩에 의지합니다. 인코딩을 잘못하면 링크가 깨지거나 오픈 리다이렉트 같은 보안 취약점이 생기거나 데이터가 손상됩니다.

이 도구는 encodeURI와 encodeURIComponent 두 모드, 내장 URL 구조 파서, 실시간 변환, 이중 인코딩 감지 기능을 제공하며 모든 동작은 브라우저 내부에서 비공개로 실행됩니다.

URL 인코딩은 다른 웹 개발 도구와 함께 자주 사용됩니다. JWT 토큰이나 API 페이로드에 포함하기 위해 URL을 Base64로 인코딩하거나, URL 문자열이 포함된 JSON 데이터를 포매팅해 구조를 확인해야 할 수 있습니다.

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

주요 기능

듀얼 인코딩 모드

URL 구조를 보존하는 encodeURI와 파라미터 값용으로 모든 문자를 인코딩하는 encodeURIComponent 사이를 전환하여 용도에 정확히 맞춥니다.

내장 URL 파서

URL을 프로토콜, 호스트, 포트, 경로, 쿼리 파라미터, 조각으로 자동 분해합니다. 각 필드는 편집 가능하며 새 URL로 재구성할 수 있습니다.

실시간 변환

입력과 동시에 인코딩하고 디코딩합니다. 버튼을 누를 필요 없이 결과가 반대편 영역에 즉시 표시됩니다.

100% 브라우저 기반

모든 처리는 네이티브 JavaScript API를 사용해 브라우저 내부에서 로컬로 이루어집니다. 서버 업로드도 추적도 없으며 데이터가 기기를 떠나지 않습니다.

완전한 UTF-8 지원

올바른 UTF-8 바이트 인코딩과 디코딩을 통해 한국어, 중국어, 일본어, 아랍어, 이모지 등 어떤 유니코드 텍스트도 정확히 처리합니다.

이중 인코딩 감지

%2520(이미 인코딩된 %20의 재인코딩) 같은 이중 인코딩 문제를 자동으로 감지하고 경고하여 가장 흔한 URL 인코딩 실수를 예방합니다.

예시

깨진 URL 디코딩

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

완전히 퍼센트 인코딩된 URL을 사람이 읽을 수 있는 형태로 디코딩하여 원래 쿼리 파라미터와 구조를 확인합니다

한자 문자

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

한자는 UTF-8 바이트 시퀀스로 변환된 뒤 퍼센트 인코딩됩니다

쿼리 파라미터

https://example.com/api?name=홍길동&role=admin&lang=ko&sort=date desc
https://example.com/api?name=%ED%99%8D%EA%B8%B8%EB%8F%99&role=admin&lang=ko&sort=date%20desc

쿼리 파라미터 값의 공백과 특수 문자는 URL 구조를 유지한 채 퍼센트 인코딩됩니다

전체 URL

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

자격 증명, 포트, 경로, 대괄호가 포함된 쿼리 파라미터, 조각 식별자를 모두 포함한 전체 URL 예시

OAuth 리다이렉트 URI

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

redirect_uri 값 자체가 전체 URL이므로 그 특수 문자가 바깥 URL의 일부로 해석되지 않도록 인코딩해야 합니다

사용 방법

  1. 1

    URL 또는 인코딩된 문자열 입력

    디코딩된 영역에 URL을 붙여넣어 인코딩하거나, 인코딩된 영역에 퍼센트 인코딩 문자열을 붙여넣어 디코딩하십시오. 용도에 따라 encodeURI 또는 encodeURIComponent 모드를 선택하십시오.

  2. 2

    결과와 파싱된 구조 확인

    입력과 동시에 반대편 영역이 즉시 갱신됩니다. URL 파서는 URL을 프로토콜, 호스트, 포트, 경로, 쿼리 파라미터, 조각으로 나누며 모두 편집 가능합니다.

  3. 3

    복사 또는 재구성

    복사를 눌러 인코딩되거나 디코딩된 결과를 복사합니다. 개별 URL 구성 요소를 편집한 뒤 재구성을 누르면 수정된 부분으로 새 URL을 만들 수 있습니다.

흔한 오류

이중 인코딩(%20 대신 %2520)

이중 인코딩은 이미 인코딩된 URL을 다시 인코딩할 때 발생합니다. %20의 %가 %25로 인코딩되면서 %20이 %2520이 됩니다. 이렇게 되면 서버가 공백이 아닌 %20 문자열 그대로를 보게 되어 URL이 깨집니다.

✗ 오류
https://example.com/path%2520with%2520spaces
✓ 정상
https://example.com/path%20with%20spaces

경로 세그먼트에서 공백을 +로 인코딩

+ 문자는 application/x-www-form-urlencoded 형식(HTML 폼 쿼리 문자열)에서만 공백을 의미합니다. URL 경로 세그먼트에서 +는 공백이 아니라 문자 그대로의 더하기 기호로 해석됩니다. 경로 세그먼트의 공백에는 항상 %20을 사용하십시오.

✗ 오류
https://example.com/my+file+name.pdf
✓ 정상
https://example.com/my%20file%20name.pdf

쿼리 파라미터 값에 encodeURI 사용

encodeURI()는 &, =를 비롯한 reserved 문자를 인코딩하지 않으므로, 이런 문자가 포함된 파라미터 값에 사용하면 쿼리 문자열 구조가 망가집니다.

✗ 오류
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ 정상
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

UTF-8이 아닌 인코딩 가정

일부 레거시 시스템은 URL 파라미터에 Latin-1이나 Shift-JIS 같은 인코딩을 사용합니다. 현대 표준은 UTF-8을 요구합니다. Shift-JIS로 인코딩된 파라미터를 UTF-8 디코더로 디코딩하면 깨진 텍스트가 나옵니다.

✗ 오류
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ 정상
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

맥락 없이 상대 경로 인코딩

../images/photo.jpg 같은 상대 경로를 encodeURIComponent로 인코딩하면 슬래시와 점이 퍼센트 인코딩 시퀀스가 되어 경로 구조가 깨집니다. encodeURI()를 사용하거나 개별 경로 세그먼트만 인코딩하십시오.

✗ 오류
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ 정상
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

일반적인 활용 사례

깨진 URL 디버깅
서버 로그, 오류 메시지, 브라우저 개발자 도구의 퍼센트 인코딩된 URL을 디코딩해 원래 사람이 읽을 수 있는 텍스트로 확인합니다.
API 개발
REST API 호출의 쿼리 파라미터 값을 인코딩하여 &, =, 공백 같은 특수 문자가 요청 URL을 깨뜨리지 않도록 합니다.
OAuth 흐름 설정
OAuth 인증 URL의 redirect_uri 등 URL 파라미터를 적절히 인코딩하여 인증 실패를 예방합니다.
국제화 URL
한국어, 중국어, 일본어, 아랍어 등 비 ASCII 문자가 포함된 URL을 국제화된 웹 애플리케이션용으로 인코딩·디코딩합니다.
마케팅 링크 분석
이메일 캠페인과 광고 플랫폼의 추적 URL을 디코딩하여 포함된 UTM 파라미터와 리다이렉트 체인을 파악합니다.
URL 구조 검사
복잡한 URL을 프로토콜, 호스트, 포트, 경로, 쿼리 파라미터, 조각 구성 요소로 파싱하여 분석하고 수정합니다.

기술 세부사항

RFC 3986의 reserved와 unreserved 문자
RFC 3986은 절대로 인코딩할 필요가 없는 unreserved 문자(A-Z, a-z, 0-9, -, ., _, ~)와 URI 구분자 역할을 하는 reserved 문자(:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =)를 정의합니다. reserved 문자는 데이터로 사용될 때는 퍼센트 인코딩되어야 합니다.
UTF-8 바이트 인코딩 흐름
비 ASCII 문자는 먼저 유니코드 코드 포인트로 변환된 뒤 UTF-8 바이트(코드 포인트 범위에 따라 1-4바이트)로 인코딩되고, 마지막으로 각 바이트가 %XX로 퍼센트 인코딩됩니다. 예: é(U+00E9) → UTF-8 바이트 C3 A9 → %C3%A9. 이모지 🎉(U+1F389) → UTF-8 바이트 F0 9F 8E 89 → %F0%9F%8E%89.
URL과 URI 용어
URI(Uniform Resource Identifier)는 임의의 식별자 문자열을 가리키는 일반 용어입니다. URL(Uniform Resource Locator)은 https://처럼 접근 방법도 함께 명시하는 URI입니다. RFC 3986의 인코딩 규칙은 모든 URI에 적용됩니다. JavaScript API는 URI 용어(encodeURI, decodeURI)를 따르며 일상에서는 URL 용어가 더 흔합니다.

모범 사례

용도에 맞는 모드 사용
개별 쿼리 파라미터 키와 값에는 encodeURIComponent()를 사용하십시오. encodeURI()는 전체 URL이 있고 구조를 깨뜨리지 않으면서 안전하지 않은 문자만 인코딩하고 싶을 때만 사용하십시오. &, =를 비롯한 reserved 문자가 포함될 수 있는 파라미터 값에는 encodeURI()를 절대 사용하지 마십시오.
이중 인코딩 피하기
문자열을 인코딩하기 전에 이미 인코딩되었는지 확인하십시오. 기존 % 시퀀스가 있는지 살펴보십시오. 이미 인코딩된 문자열을 또 인코딩하면 %20이 %2520이 되고 %3D가 %253D가 됩니다. 확신이 없다면 먼저 디코딩한 뒤 한 번만 인코딩하십시오.
서버 측 디코딩
대부분의 웹 프레임워크는 애플리케이션 코드가 값을 받기 전에 URL 파라미터를 자동으로 디코딩합니다. 프레임워크가 이미 디코딩한 파라미터를 수동으로 또 디코딩하지 마십시오. 원본 값에 퍼센트 시퀀스가 들어 있으면 문제가 생길 수 있습니다.
OAuth와 API 서명을 위한 값 인코딩
OAuth 1.0 서명 기반 문자열과 많은 API 서명 알고리즘은 엄격한 RFC 3986 퍼센트 인코딩을 요구합니다. encodeURIComponent()를 사용한 뒤 해당 함수가 인코딩하지 않는 문자(!, ', (, ), *)를 명세가 요구하면 직접 퍼센트 인코딩 등가물로 치환하십시오.

자주 묻는 질문

URL 인코딩은 무엇이며 왜 필요한가요?
URL 인코딩(퍼센트 인코딩)은 안전하지 않은 문자를 %XX 16진수 시퀀스로 변환하여 URL에 안전하게 포함할 수 있게 하는 방식입니다. 공백, 앰퍼샌드, 비 ASCII 텍스트 같은 문자는 인코딩하지 않으면 URL 구조를 깨뜨리거나 브라우저와 서버가 잘못 해석하므로 반드시 인코딩해야 합니다. RFC 3986에 정의된 이 메커니즘은 URL이 제한된 US-ASCII 문자 집합만 포함할 수 있기 때문에 필요합니다. 알파벳(A-Z, a-z), 숫자(0-9), 하이픈, 언더스코어, 마침표, 틸드 같은 소수의 기호가 허용됩니다. 안전 집합 밖의 문자는 해당 바이트 값을 나타내는 16진수 두 자리가 퍼센트 기호(%) 뒤에 붙는 형태로 인코딩됩니다. 예를 들어 공백은 %20, 슬래시는 %2F, 앰퍼샌드는 %26이 됩니다. &, =, ?, # 같은 문자는 URL에서 쿼리 파라미터와 조각 등을 구분하는 구조적 의미를 가집니다. 인코딩하지 않으면 파라미터 값 안의 &가 파라미터 구분자로 잘못 해석되어 URL 구조가 깨집니다.
encodeURI와 encodeURIComponent의 차이는 무엇인가요?
encodeURI()는 전체 URL을 인코딩하면서 :, /, ?, # 같은 구조 문자를 보존합니다. encodeURIComponent()는 알파벳, 숫자, -, _, ., ~를 제외한 모든 문자를 인코딩하므로 개별 쿼리 파라미터 값을 인코딩할 때 올바른 선택입니다. 파라미터 키와 값에는 encodeURIComponent()를, 전체 URL에는 encodeURI()만 사용하십시오. 예를 들어 encodeURI('https://example.com/path name')는 'https://example.com/path%20name'을 생성하며 ://와 /를 보존합니다. encodeURIComponent()는 훨씬 공격적으로 :, /, ?, #, &, =를 인코딩합니다. 앰퍼샌드가 포함된 파라미터 값에 encodeURI()를 사용하면 &가 인코딩되지 않은 채 통과되어 파라미터 구분자로 잘못 해석됩니다. encodeURIComponent()는 그것을 %26으로 올바르게 인코딩합니다. 두 함수를 혼동하는 것이 웹 애플리케이션에서 가장 흔한 URL 관련 버그의 원인입니다.
URL 인코딩은 HTML 인코딩과 같은가요?
아니요. URL 인코딩은 URL용으로 문자를 %XX 16진수 시퀀스로 변환(RFC 3986)하는 반면, HTML 인코딩은 HTML 문서에서 문자를 &, < 같은 엔티티로 변환합니다. 목적이 완전히 다르므로 절대 서로 바꾸어 쓰면 안 됩니다. URL 인코딩은 URL 내부의 데이터 전송용이어서 공백은 %20이 됩니다. HTML 인코딩은 HTML에서 내용을 안전하게 표시하기 위한 것이어서 앰퍼샌드는 &가 됩니다. URL 파라미터에 HTML 인코딩을 적용하거나 그 반대로 하는 것이 흔한 실수입니다. 예를 들어 URL에서 공백을  로 인코딩하면 동작하지 않으며 반드시 %20 또는 +여야 합니다. 마찬가지로 HTML 텍스트에서 < 대신 %3C를 사용해도 원하는 이스케이프 효과를 얻지 못합니다.
curl 명령에서 URL이 깨지는 이유는 무엇인가요?
셸이 특수 URL 문자를 curl에 전달되기 전에 해석하기 때문입니다. &는 명령을 백그라운드로 실행하고, ?는 글롭을 유발하며, #은 주석을 시작합니다. URL을 작은따옴표로 감싸서 해결하십시오: curl 'https://example.com/api?key=value&page=2#section'. 작은따옴표는 셸이 어떤 특수 문자도 해석하지 않도록 막습니다. 가장 흔한 원인은 앰퍼샌드(&)입니다. 앞 명령을 백그라운드로 실행하라고 셸에 지시하여 첫 &에서 URL이 끊기고 이후 부분이 버려집니다. 대안으로 각 문자를 백슬래시로 이스케이프할 수도 있지만 URL 전체를 인용부호로 감싸는 편이 더 간단하고 실수가 적습니다. URL에 작은따옴표까지 포함되어 있다면 큰따옴표를 사용하고 달러 기호나 백틱은 이스케이프하십시오.
한자가 URL에서 %E4%B8%AD 같은 문자열로 바뀌는 이유는 무엇인가요?
한자는 먼저 UTF-8 바이트로 변환되고, 그다음 각 바이트가 %XX로 퍼센트 인코딩됩니다. 문자 中(U+4E2D)은 UTF-8 바이트 세 개(E4, B8, AD)가 되어 %E4%B8%AD가 되며, 그래서 한자 하나가 URL에서 9자로 늘어납니다. 문자를 유니코드 코드 포인트로, 코드 포인트를 UTF-8 바이트로, 바이트를 퍼센트 인코딩 16진수로 바꾸는 이 3단계 과정은 모든 비 ASCII 문자에 적용됩니다. 이모지는 보통 4바이트 UTF-8이어서 퍼센트 인코딩 시 12자로 늘어납니다. URL이 디코딩될 때는 반대 과정이 일어납니다. 16진수 값이 바이트로 변환되고, 바이트는 UTF-8로 해석되어 원래 문자가 복원됩니다.
OAuth redirect_uri 파라미터도 인코딩해야 하나요?
예, 항상 encodeURIComponent()로 인코딩하십시오. redirect_uri는 쿼리 파라미터 값으로 삽입되는 전체 URL이므로 특수 문자(?, &, =)가 바깥 URL 구조의 일부로 잘못 해석되지 않도록 인코딩해야 합니다. 예를 들어 인코딩 없이 redirect_uri=https://myapp.com/callback?code=abc&state=xyz를 보내면 인증 서버는 redirect_uri를 https://myapp.com/callback?code=abc까지만 인식하고 state=xyz는 바깥 URL의 별도 파라미터로 파싱합니다. 올바르게 인코딩된 버전은 redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz입니다.
Node.js querystring과 URLSearchParams의 차이는 무엇인가요?
새 프로젝트에서는 URLSearchParams를 사용하십시오. WHATWG 표준이며 브라우저 동작과 일치하고 Node.js와 브라우저에서 동일하게 동작합니다. querystring 모듈은 레거시이며 더 이상 적극적으로 개발되지 않습니다. 주요 차이점은 URLSearchParams가 공백을 +(폼 인코딩 표준)로 인코딩하고, getAll()로 반복되는 키를 처리하며, entries(), keys(), values() 메서드로 반복 가능한 인터페이스를 제공한다는 점입니다. querystring 모듈은 공백을 %20으로 인코딩하고 배열 처리에 독특한 점이 있습니다(key=1&key=2가 { key: ['1', '2'] }로 처리됨). URLSearchParams는 표준을 준수하며 Node.js 공식 문서가 권장하는 방식입니다.
Python, JavaScript, Java에서 URL은 어떻게 인코딩하나요?
JavaScript: encodeURIComponent('hello world')는 'hello%20world'를 만듭니다. Python: urllib.parse.quote('hello world')는 'hello%20world'를 만듭니다. Java: URLEncoder.encode('hello world', StandardCharsets.UTF_8)는 'hello+world'를 만듭니다(RFC 3986을 위해 +를 %20으로 바꿀 것). JavaScript에서는 파라미터 값에는 encodeURIComponent(), 전체 URL에는 encodeURI()를 사용하십시오. Python 3에서는 경로 세그먼트에 urllib.parse.quote(), 쿼리 파라미터에 urllib.parse.urlencode()를 사용하며, urlencode({'q': 'hello world'})는 'q=hello+world'를 만듭니다. Java에서 URLEncoder는 폼 인코딩(공백을 +)을 사용한다는 점에 유의하십시오. 완전한 URI를 구성할 때는 java.net.URI 또는 Apache HttpClient의 URIBuilder 클래스를 사용하십시오.
URL 인코딩에서 인코딩되지 않는 문자는 무엇인가요?
RFC 3986은 절대로 인코딩할 필요가 없는 66개의 unreserved 문자를 정의합니다: A-Z, a-z, 0-9, 하이픈(-), 마침표(.), 언더스코어(_), 틸드(~). 이들은 URL의 어느 부분에서도 문자 그대로 등장할 수 있습니다. reserved 문자 :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ;, =는 쿼리 문자열의 ?처럼 구조적 역할로는 허용되지만, 데이터로 사용할 때는 퍼센트 인코딩해야 합니다. JavaScript에서 encodeURIComponent()는 A-Z a-z 0-9 - _ . ~ 와 ! ' ( ) *를 제외한 모든 것을 인코딩하고, encodeURI()는 URL 구분자 역할을 하는 reserved 문자도 추가로 보존합니다.
공백을 인코딩할 때 +와 %20의 차이는 무엇인가요?
둘 다 공백을 나타내지만 %20이 보편적으로 안전한 선택입니다. + 관례는 HTML 폼 인코딩(application/x-www-form-urlencoded)에서 나왔으며 쿼리 문자열에서만 작동합니다. URL 경로 세그먼트에서 +는 공백이 아니라 문자 그대로의 더하기 기호입니다. 확신이 없다면 %20을 사용하십시오. + 인코딩은 HTML 명세에서 유래했으며 브라우저가 폼을 제출할 때 공백은 +가 되고 + 자체는 %2B가 됩니다. %20 인코딩은 RFC 3986(URI 구문)에서 유래했으며 unreserved가 아닌 모든 문자가 퍼센트 기호와 두 개의 16진수로 인코딩됩니다. %20은 URL의 모든 부분(경로, 쿼리, 조각)에서 동작합니다.
URL 인코딩은 이모지를 어떻게 처리하나요?
이모지 하나는 보통 URL에서 12자로 늘어납니다. 이모지는 UTF-8 바이트(대개 4바이트)로 변환된 뒤 각 바이트가 %XX로 퍼센트 인코딩됩니다. 예를 들어 🚀(U+1F680)는 %F0%9F%9A%80이 됩니다. 대부분의 이모지는 U+1F000부터 U+1FFFF 이상 범위의 코드 포인트를 사용하며 UTF-8에서 4바이트를 차지합니다. 피부색 수정자나 ZWJ 시퀀스가 포함된 일부 이모지는 여러 코드 포인트로 구성되어 인코딩 시 30자 이상으로 늘어날 수 있습니다. 이렇게 크기가 커져도 인코딩은 완전히 가역적이며 %F0%9F%9A%80을 디코딩하면 🚀이 정확히 복원됩니다.
URL 인코딩을 암호나 보안 용도로 사용할 수 있나요?
아니요. URL 인코딩은 암호가 아니며 보안 기능을 전혀 제공하지 않습니다. 완전히 가역적이고 결정적인 변환이어서 누구나 키나 비밀 없이도 퍼센트 인코딩 문자열을 즉시 디코딩할 수 있습니다. 특수 문자를 URL 전송에 안전하도록 이스케이프하는 용도만 합니다. URL 인코딩을 난독화나 보안으로 여기는 것은 위험한 오해입니다. 비밀번호, 토큰, 개인 정보 같은 민감한 데이터는 URL 인코딩이 아니라 HTTPS(요청 전체의 TLS 보호)로 보호되어야 합니다. 또한 URL은 서버 로그, 브라우저 기록, 리퍼러 헤더에 자주 노출되므로 민감한 데이터는 일반적으로 URL이 아니라 요청 본문에 담아야 합니다.
URL의 최대 길이는 얼마인가요?
공식적인 최댓값은 없지만 호환성을 최대화하려면 URL을 2,000자 이하로 유지하십시오. 대부분의 브라우저는 약 2,048자를 지원하며, Apache는 기본적으로 8,190바이트, Nginx는 8,192바이트까지 지원합니다. 큰 데이터는 POST 요청을 사용하십시오. HTTP 명세(RFC 7230)는 URL 길이의 최댓값을 정의하지 않지만 각 계층마다 실용적인 제한이 존재합니다. Chrome과 Firefox는 10만 자가 넘는 URL도 처리할 수 있지만 IIS는 쿼리 문자열을 16,384바이트로 제한합니다. CDN과 프록시는 더 엄격한 제한을 둘 수 있습니다. URL 인코딩으로 특히 비 ASCII 텍스트가 확장되면 짧아 보이던 URL이 빠르게 이 한계에 도달합니다.
URL과 URI의 차이는 무엇인가요?
URI(Uniform Resource Identifier)는 자원을 식별하는 모든 문자열을 의미합니다. URL(Uniform Resource Locator)은 https://처럼 접근 방법도 명시하는 URI입니다. 모든 URL은 URI이지만 모든 URI가 URL은 아닙니다. 예를 들어 urn:isbn:0451450523 같은 URN은 ISBN으로 책을 식별하지만 어디서 찾을지를 알려 주지는 않습니다. 일상적인 웹 개발에서는 URL과 URI 용어를 혼용하는 경우가 많습니다. RFC 3986의 인코딩 규칙은 두 개념 모두에 적용됩니다. JavaScript 함수 이름이 encodeURI/decodeURI인 것은 더 넓은 URI 용어를 반영한 것이며, 대부분의 개발자는 URL만을 다룹니다.

Base64 디코더 · 인코더 (Base64 Decoder & Encoder)

인코딩 & 포매팅

Base64를 온라인에서 무료로 인코딩하고 디코딩합니다. UTF-8과 이모지를 완벽 지원하는 실시간 변환으로, 100% 브라우저에서 처리되어 회원 가입이 필요 없습니다.

JSON 포맷터 (JSON Formatter)

인코딩 & 포매팅

브라우저에서 JSON을 즉시 포매팅하고 유효성 검사를 수행합니다. 온라인 도구로 구문 검사, 오류 감지, 최소화, 복사를 지원하며 데이터는 서버로 전송되지 않습니다.

진법 변환기 (Number Base Converter)

변환 도구

2진수, 16진수, 10진수, 8진수 및 임의 진법(2-36)을 즉시 변환합니다. 온라인에서 무료로 사용할 수 있으며 모든 처리는 브라우저에서 이루어집니다.

이미지 압축기 · JPEG, PNG, WebP 온라인 압축

변환 도구

JPEG, PNG, WebP 이미지를 브라우저에서 최대 80% 압축합니다. 업로드 없이 20장 일괄 처리, 품질 조절, 전후 비교를 무료로 지원합니다.

길이 변환기 · 미터법, 야드파운드법, 천문 단위

변환 도구

16개 길이 단위를 즉시 변환합니다. 미터법, 야드파운드법, 해리, 천문 단위까지. 1 inch = 2.54 cm. 온라인에서 무료로, 브라우저에서 바로 실행됩니다.

MD5 해시 생성기 · 파일 체크섬 도구

보안 도구

MD5, SHA-256, SHA-1, SHA-512 해시를 온라인에서 무료로 생성합니다. 브라우저에서 텍스트나 파일을 해싱하고 체크섬을 검증하며 결과를 복사할 수 있습니다.