HTML 엔티티 인코더 & 디코더

텍스트를 붙여넣어 특수 문자를 HTML 엔티티로 인코딩하거나, 엔티티가 포함된 HTML을 붙여넣어 읽을 수 있는 텍스트로 디코딩하세요. 이름 엔티티(&, <, ©), 십진수(©), 16진수(©) 중에서 선택할 수 있습니다. 최대 호환성을 위해 모든 비-ASCII 문자를 선택적으로 인코딩할 수도 있습니다.

모든 비-ASCII 문자 인코딩

입력 텍스트

인코딩 출력

작동 방식

HTML 엔티티란 무엇인가?

HTML 엔티티는 HTML에서 특별한 의미를 가지거나 직접 입력할 수 없는 문자를 나타내는 데 사용되는 특수 텍스트 코드입니다. 가장 중요한 것은 HTML 구문에서 예약된 다섯 문자입니다: & (앰퍼샌드) → &, < (미만 부호) → <, > (초과 부호) → >, " (큰따옴표) → ", ' (작은따옴표) → '. 이 문자들이 인코딩 없이 텍스트 콘텐츠에 나타나면 브라우저가 HTML 마크업으로 해석하여 렌더링 오류나 보안 취약점을 일으킬 수 있습니다.

HTML 엔티티는 세 가지 형식으로 존재합니다. 이름 엔티티는 설명적인 이름을 사용합니다(© 에는 ©, € 에는 €). 십진수 문자 참조는 코드 포인트 번호를 사용합니다(© 에는 ©). 16진수 문자 참조는 16진수 코드를 사용합니다(© 에는 ©). 세 형식은 모두 동등하며 브라우저는 어떤 형식을 사용하든 동일한 문자를 렌더링합니다. 이름 엔티티가 가장 읽기 쉽고, 숫자 엔티티는 모든 Unicode 문자에 작동하므로 가장 범용적입니다.

HTML 엔티티를 인코딩해야 하는 경우

텍스트 콘텐츠나 속성 값에 다섯 가지 예약 HTML 문자(&, <, >, ", ')가 나타날 때는 최소한 이를 인코딩해야 합니다. 인코딩을 하지 않으면 Cross-Site Scripting (XSS) 취약점의 원인이 됩니다. 사용자 입력이 인코딩 없이 HTML에 삽입되면 공격자가 스크립트 태그나 이벤트 핸들러를 주입할 수 있습니다. React, Vue, Angular와 같은 현대 프레임워크는 기본적으로 HTML을 자동 인코딩하지만, innerHTML은 수동 인코딩이 여전히 중요한 주요 예외입니다.

필수 다섯 문자 외에도 UTF-8을 안정적으로 처리하지 못하는 환경, 즉 이메일 HTML, 레거시 CMS 시스템, 최대 호환성이 요구되는 문서에서는 비-ASCII 문자도 인코딩하는 것이 좋습니다. '모든 비-ASCII 인코딩' 옵션은 코드 포인트 127 이상의 모든 문자를 숫자 엔티티로 변환하여 렌더링 시 시각적 외관을 보존하면서 출력이 순수한 ASCII가 되도록 합니다. 최신 UTF-8 HTML 파일의 경우 비-ASCII 인코딩은 선택 사항이며, charset을 올바르게 선언하는 것으로 충분합니다.

HTML 엔티티 vs URL 인코딩 vs Base64

HTML 엔티티, URL 인코딩(퍼센트 인코딩), Base64는 각각 다른 컨텍스트를 위한 세 가지 인코딩 방식입니다. HTML 엔티티(& 등)는 HTML 문서 내에서 문자를 안전하게 표현하는 데 사용됩니다. URL 인코딩(& 에 대해 %26)은 URL에서 특별한 의미를 가진 문자를 쿼리 문자열과 URL에서 인코딩하는 데 사용됩니다. Base64는 임의의 바이너리 데이터를 ASCII 텍스트로 인코딩하며, 데이터 URI와 이메일 첨부 파일에 사용됩니다.

흔한 실수는 이들을 혼동하는 것입니다. HTML 콘텐츠에 URL 인코딩을 사용하거나 URL에 HTML 인코딩을 사용하는 것이 대표적입니다. 예를 들어 URL 쿼리 문자열의 앰퍼샌드는 퍼센트 인코딩(%26)이 필요하며, HTML 엔티티 인코딩(&)이 아닙니다. HTML 속성에 포함될 URL을 구성할 경우 두 가지 모두 필요합니다. URL 인코딩된 형식이 속성에 들어가고, 속성 값 자체는 HTML 인코딩됩니다. 어떤 컨텍스트에 어떤 인코딩이 적용되는지 이해하면 이중 인코딩 버그와 보안 문제를 예방할 수 있습니다.

자주 묻는 질문

›앰퍼샌드(&)의 HTML 엔티티는 무엇인가요?

앰퍼샌드의 HTML 엔티티는 & 입니다. 문자 그대로 &, a, m, p, 세미콜론으로 구성됩니다. HTML 소스에 & 를 쓰면 브라우저는 단일 & 문자를 표시합니다. 이 인코딩은 텍스트 콘텐츠나 속성 값에 앰퍼샌드가 나타날 때 필수입니다. 인코딩되지 않은 & 는 파서가 엔티티 시퀀스의 시작으로 해석하려 하기 때문입니다.

›저작권 기호(©)의 HTML 엔티티는 무엇인가요?

›HTML에서 따옴표를 인코딩해야 하나요?

큰따옴표(")는 큰따옴표로 구분된 HTML 속성 내에서 " 로 인코딩해야 합니다(<input value=""">). 작은따옴표(')는 작은따옴표로 구분된 속성 내에서 ' 또는 ' 로 인코딩해야 합니다. 요소의 텍스트 콘텐츠(태그 사이)에서는 두 따옴표 문자 모두 인코딩 없이 사용할 수 있지만 인코딩해도 무방합니다. 모든 컨텍스트에서 두 가지 모두를 일관되게 인코딩하는 것이 가장 안전한 접근 방식입니다.

›이름 엔티티와 숫자 엔티티의 차이는 무엇인가요?

이름 엔티티는 설명적인 단어를 사용합니다(©, €, &hearts;). HTML 사양에서 정의되며 모든 Unicode 문자에 이름 엔티티가 있는 것은 아닙니다. 숫자 엔티티는 Unicode 코드 포인트를 사용하며 십진수(€ 에 €) 또는 16진수(€ 에 €)로 표현합니다. 숫자 엔티티는 모든 Unicode 문자에 사용할 수 있지만 이름 엔티티는 일부만 커버합니다. 둘 다 브라우저에서 동일하게 렌더링됩니다.

›HTML에서 비-ASCII 문자를 인코딩해야 하나요?

보통은 필요하지 않습니다. HTML 문서가 UTF-8 인코딩(meta charset=utf-8)을 선언하고 UTF-8로 저장된 경우 비-ASCII 문자를 직접 쓸 수 있습니다(é, ñ, 中, 🎉 등). 엔티티로 인코딩하는 것은 선택 사항이며 소스를 읽기 어렵게 만듭니다. 예외는 인코딩이 보존되지 않을 수 있는 컨텍스트에서 HTML을 전송할 때입니다. 이메일 메시지, 레거시 API, 비-ASCII 바이트를 손상시키는 시스템 등이 해당됩니다. 이 경우 모든 비-ASCII를 숫자 엔티티로 인코딩하면 출력이 순수하고 안전한 ASCII가 됩니다.

›XSS란 무엇이고 HTML 엔티티는 어떻게 이를 방지하나요?

Cross-Site Scripting (XSS)은 공격자가 서버가 인코딩 없이 HTML에 반영하는 텍스트를 삽입하여 악성 JavaScript를 웹 페이지에 주입하는 보안 취약점입니다. 예를 들어 사용자 입력 <script>alert('xss')</script>가 페이지에 직접 삽입되면 브라우저가 스크립트를 실행합니다. 입력을 올바르게 인코딩하여 < 를 < 로, > 를 > 로 변환하면 브라우저는 태그로 파싱하는 대신 텍스트를 문자 그대로 표시합니다. HTML 엔티티 인코딩은 반사형 및 저장형 XSS에 대한 주요 방어 수단입니다.

›왜   가 이 도구의 목록에 나타나지 않나요?

이 도구는 이름 엔티티를 가진 문자를 인코딩합니다. 줄바꿈 없는 공백(Unicode U+00A0)은 실제 줄바꿈 없는 공백 문자를 입력하면   로 인코딩됩니다(일부 시스템에서 Alt+Space로 삽입하거나 문자 맵에서 복사할 수 있습니다). 일반 공백(U+0020, 스페이스바)은 안전한 ASCII 문자이므로 인코딩되지 않습니다. 출력에   가 특별히 필요한 경우 입력에 줄바꿈 없는 공백 문자를 입력하거나 붙여넣으세요.

›사용자 입력의 HTML 인젝션 방지에 이 도구를 사용할 수 있나요?

네, 사용자가 제공한 텍스트를 HTML에 삽입하기 전에 인코딩하는 것은 HTML 인젝션과 XSS에 대한 핵심 방어 수단 중 하나입니다. 최소한 다섯 가지 예약 문자(&, <, >, ", ')를 인코딩하세요. 이 도구는 다섯 가지 모두를 인코딩합니다. 그러나 인코딩만으로는 완전한 보안 솔루션이 되지 않습니다. 적절한 Content Security Policy 헤더, 속성의 javascript: URL 신중한 처리, 프레임워크 수준의 보호도 필요합니다. 프로덕션 애플리케이션에서는 수동 인코딩 대신 보안을 위해 설계된 서버 측 라이브러리(OWASP Java Encoder, 클라이언트 측 DOMPurify 등)를 사용하세요.