최근 사용한 도구가 없습니다
즐겨찾기한 도구가 없습니다

URL 인코더 무료 온라인: URL 인코딩 디코딩 즉시 변환

758 회 사용

URL 인코딩 참조

문자인코딩됨설명
공백%20 / +가장 일반적인 URL 이스케이프 문자
!%21느낌표
#%23해시, URL 앵커 기호
%%25퍼센트 기호 (반드시 이스케이프)
&%26URL 매개변수 구분자
=%3DURL 매개변수 할당
?%3F쿼리 문자열 시작
/%2F경로 구분자

URL 인코딩 팁

퍼센트 인코딩이란
URL 인코딩은 특수문자를 %XX(16진수 값)로 대체합니다. 공백은 %20, &는 %26, =는 %3D가 됩니다. 유효한 URL에 필수입니다.
참조 표
자주 사용되는 문자와 URL 인코딩 값이 정리된 표를 확인하세요.
인코딩된 URL 디코딩
%XX 문자가 포함된 URL을 붙여넣으면 원본 텍스트를 확인합니다. URL 파라미터 디버깅과 링크 분석에 유용합니다.

자주 묻는 질문

Q %20과 +의 차이는?
A %20은 URL에서 공백의 표준 인코딩입니다. +는 폼(application/x-www-form-urlencoded)에서만 공백 대체로 사용됩니다.
Q 다른 문자 세트를 사용하여 텍스트를 직접 인코딩할 수 있습니까?
A 이 도구는 문자 세트 변환이 아닌 URL 인코딩에 중점을 둡니다. 입력 텍스트가 UTF-8과 같은 표준 세트라고 가정합니다. 다른 인코딩의 텍스트가 있는 경우, 적절한 퍼센트 인코딩을 보장하려면 이 인코더를 사용하기 전에 UTF-8로 변환해야 합니다. 문자열이 UTF-8 바이트로 표현되었는지 확인한 후 여기에 입력하십시오.
Q encodeURI가 ?나 = 같은 문자를 그대로 두는 이유는?
A encodeURI는 전체 URL을 인코딩하기 위한 것이지, 매개변수 값을 위한 것이 아닙니다. URL에서 특별한 의미를 가진 ?, #, /, = 같은 문자는 그대로 유지합니다. 이런 문자도 인코딩해야 한다면 encodeURIComponent를 사용하세요. 예를 들어 encodeURI는 ?를 그대로 두지만 encodeURIComponent는 %3F로 변환합니다. URL의 어떤 부분을 인코딩하는지에 따라 이 도구에서 올바른 모드를 선택하세요.
Q 브라우저 주소창에 표시된 인코딩된 URL이 제가 입력한 것과 다른 이유는 무엇인가요?
A 브라우저는 종종 URL을 자동으로 정규화합니다. 예를 들어 주소창에 공백을 입력하면 %20으로 변환되지만 일부 브라우저는 다시 공백으로 표시합니다. 저희 도구는 네트워크를 통해 실제로 전송되는 원시 퍼센트 인코딩 출력을 보여줍니다. 브라우저의 주소를 디코더에 붙여넣어 실제 기본 문자를 확인하세요. 이 불일치는 많은 개발자를 놀라게 합니다.
Q URL 인코딩과 HTML 엔티티 인코딩의 차이점이 있나요?
A 완전히 다른 시스템입니다. URL 인코딩은 공백을 %20으로 바꾸지만, HTML 엔티티 인코딩은  나  을 사용합니다. 혼동하면 링크가 깨지거나 페이지에 원시 코드가 표시됩니다. 이 도구는 URL 인코딩 전용입니다. JSON API 응답에서 & 대신 &이 보인다면, URL 문제가 아니라 HTML 인코딩이 새어 나온 겁니다.
Q 실수로 두 번 인코딩된 URL을 디코딩할 수 있나요?
A 이중 인코딩은 이미 퍼센트 인코딩된 문자열을 또 인코딩할 때 발생합니다. %20 대신 %2520이 보이는 식이죠. 디코더에 한 번 돌리고 결과에 여전히 % 기호가 있으면 다시 디코딩하세요. 세 번까지 필요할 일은 거의 없습니다. 결제 게이트웨이 콜백이 깨져 보인다면 대부분 이게 원인입니다.
Q URL 인코딩이 데이터를 암호화해서 안전하게 공유할 수 있게 해주나요?
A 전혀 아닙니다. URL 인코딩은 단순한 형식 변환일 뿐입니다. 공백을 %20으로, 특수 문자를 퍼센트 코드로 바꿔줄 뿐이에요. 누구나 이 도구로 즉시 디코딩할 수 있습니다. 샌드위치를 랩으로 싸는 것과 같아요. 깔끔하지만 속이 훤히 보이죠. 비밀번호나 API 키 같은 민감한 정보를 URL로 공유한다면 진짜 암호화(HTTPS가 전송을 보호)나 해싱을 사용하세요. 인코딩만으로는 보안이 전혀 없습니다.
Q 뉴스레터 링크를 편집기에서 복사하면 왜 깨지나요?
A 이메일 편집기는 공백과 특수 문자를 제멋대로 인코딩하는 경우가 많습니다. 편집기에서는 깔끔해 보여도 발송 후에 공백이 %20으로 바뀌거나 첫 공백에서 링크가 잘립니다. 이 디코더에 링크를 붙여넣어 실제 포함된 문자를 확인해보세요. `&` 대신 `&` 하나만 보인다면, 그건 URL 인코딩이 아니라 HTML 인코딩입니다. 팁: 템플릿에 넣기 전에 쿼리 문자열 전체를 `encodeURIComponent`로 인코딩하세요.
Q 이미 인코딩된 문자가 포함된 URL을 디코더에 붙여넣으면 어떻게 되나요?
A 디코더는 원래의 퍼센트 인코딩 바이트를 그대로 표시할 뿐, 더 이상 아무것도 처리하지 않습니다. 예를 들어 `%2520`는 첫 번째 실행에서 `%20`으로 디코딩되지, 공백이 되지 않습니다. 이중 인코딩이 의심되면 다시 실행하세요 — 두 번째 실행에서야 공백이 보입니다. 데이터 파이프라인이 쿼리 문자열을 실수로 삼중 인코딩하는 경우를 본 적이 있으니, API 로그가 이상하면 두 번 확인하세요. 스프레드시트 내보내기를 정리할 때는 한 번 디코딩한 후 남은 `%` 기호를 검색하는 것이 좋습니다.
Q URL 인코딩과 Base64 인코딩은 같은 것인가요?
A 아니요, 둘을 혼동하면 큰 문제가 생깁니다. URL 인코딩은 % 기호와 16진수를 사용하며 공백은 %20이 됩니다. Base64는 A-Z, a-z, 0-9, 더하기, 슬래시라는 완전히 다른 문자 집합으로 바이너리 데이터를 텍스트로 변환합니다. 이 도구에서 Base64 문자열을 디코딩하면 깨진 출력이나 오류가 나옵니다. 구별하는 팁: Base64 문자열은 끝에 = 패딩이 붙는 경우가 많고 원본보다 훨씬 깁니다. API용 서명 링크를 만들 때는 문서를 꼭 확인하세요. 일부 시스템은 +와 /를 -와 _로 바꾼 Base64url을 요구합니다. 그 형식도 이 도구에서 제대로 처리되지 않습니다.

URL 인코딩/디코딩 사용 방법

관련 도구