🚀 빠른 시작

위 입력란에 URL/텍스트/CJK 등을 입력
인코딩 또는 디코딩을 클릭해 모드 전환
버튼 클릭 시 변환 시작, 결과는 같은 텍스트 영역에 표시
아래 복사 버튼을 사용

📌 자주 쓰는 활용 사례

API 매개변수: 쿼리/본문 데이터를 인코딩하여 특수 문자를 정확히 전송
폼 제출: GET/POST 데이터를 처리, CJK 및 특수 기호 지원
공유 링크: CJK/특수 문자를 포함한 URL을 깨짐 없이 생성
검색어: & = # ? 등을 포함할 때 인코딩

🧭 활용 팁

이중 인코딩 방지: %XX 시퀀스가 이미 있는지 확인
부분 인코딩: 매개변수 값만 인코딩(예: ?key=encoded)하고 URL 구조 유지
디버깅: 네트워크 요청의 매개변수를 디코딩하여 문제를 신속히 파악
예약 문자: : / ? # [ ] @ ! $ & ' ( ) * + , ; = 는 특수한 의미가 있어 데이터로 사용할 때 보통 인코딩 필요(문맥 의존, 특히 : / ? # & = +)
문자 인코딩: 비 ASCII 문자는 UTF‑8 1–4바이트로 인코딩, 각 바이트는 %HH로 표기

⚠️ 제한 사항 및 호환성

URL 인코딩 ≠ 암호화: 되돌릴 수 있는 형식 변환이며 민감 정보 보호를 제공하지 않습니다
URL 길이: 총 길이 < 2048 문자 권장(브라우저/서버에 따라 상이)
공백 차이: 쿼리 문자열에서는 +(폼 인코딩) 또는 %20(일반). 본 도구는 기본값으로 %20 사용
아주 긴 텍스트: 브라우저가 응답하지 않거나 중단될 수 있으므로, 나눠서 처리 권장

🔒 개인정보 보호 및 보안

모든 처리는 브라우저 내에서 이루어지며, 데이터는 기기를 떠나지 않습니다
비밀번호, 키, 토큰 등 민감 정보는 인코딩이 아닌 암호화를 사용

❓ 자주 묻는 질문

URL이 무엇이고 왜 ‘인코딩’하나요?

URL(Uniform Resource Locator)은 팀 버너스‑리가 1990년대 Web을 위해 도입한 ‘리소스 주소’로, scheme/host/path/query/fragment 구조를 사람이 읽을 수 있는 문자열로 표현합니다. 데이터 문자가 구분자(? & # = /)로 오인되거나 공백·한글·emoji 같은 비 ASCII를 처리하기 위해, 이러한 문자를 %HH 형태의 percent‑encoding으로 변환합니다(예: 공백→%20, 파라미터 값의 /→%2F). 폼 문맥(application/x‑www‑form‑urlencoded)에서는 공백을 ‘+’로 표기할 수 있으며, 폼 외부에서는 %20을 권장합니다. URL 인코딩은 링크 안정성을 위한 가역적 포맷 변환이며, 암호화나 기밀 보장을 제공하지 않습니다.

인코딩이 민감 정보를 보호하나요?

아니오. 인코딩은 되돌릴 수 있는 형식 변환입니다. 비밀번호나 API 키 등은 암호화해야 합니다

공백이 어떤 때는 +, 어떤 때는 %20 인 이유는?

폼(application/x-www-form-urlencoded)에서는 +, 일반적인 RFC 3986에서는 %20을 사용합니다. 본 도구는 호환성을 위해 %20을 기본으로 사용합니다. +가 필요하면 폼 문맥에서 사용하거나 수동 치환

이미 인코딩되었는지 어떻게 확인하나요?

% 다음에 16진수 두 자리가 오는 %XX 시퀀스가 많이 보이면 이미 인코딩된 것입니다. 재인코딩을 피하세요

왜 비 ASCII 문자는 인코딩해야 하나요?

URL 표준은 ASCII만 허용합니다. 비 ASCII 텍스트(예: 악센트 문자, 이모지)는 안전한 전송을 위해 UTF‑8 바이트를 %HH로 표기하는 퍼센트 인코딩이 필요합니다

슬래시 / 도 인코딩해야 하나요?

위치에 따라 다릅니다. 경로 구분자일 때는 인코딩하지 않습니다(예: /api/users). 매개변수 값이라면 %2F로 인코딩합니다(예: ?path=%2Fhome%2Fuser)