HTML spellcheck 속성 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

HTML spellcheck 속성 기준 정리

spellcheck는 브라우저가 편집 가능한 텍스트에 맞춤법과 문법 표시를 제공해도 되는지를 나타내는 HTML 전역 속성이다. 2026년 7월 26일 확인 기준 WHATWG HTML Living Standard는 이 속성을 편집 가능한 텍스트, textarea, 그리고 일부 input 타입에 적용되는 규칙으로 정의한다.

실무에서는 "폼 입력에서 빨간 밑줄을 꺼야 하는가", "상위 요소에 한 번만 지정해도 되는가", "브라우저 설정과 무엇이 충돌하는가"가 핵심 질문이 된다. 이 글은 표준 문서에 있는 범위 안에서 spellcheck의 의미와 선택 기준만 정리한다.

spellcheck는 무엇을 제어할까?

spellcheck는 입력값의 유효성을 검사하는 기능이 아니라, 사용자 에이전트가 맞춤법과 문법 검사를 제공할지에 대한 힌트를 주는 속성이다. 표준은 사용자 인터페이스를 강제하지 않으며, 브라우저는 실시간 표시, 요청 시 검사, 다른 형태의 UI 가운데 하나를 선택할 수 있다.

따라서 spellcheck="false"를 넣었다고 해서 모든 브라우저와 운영체제에서 완전히 같은 방식으로 동작한다고 단정할 수는 없다. 반대로 spellcheck="true"도 입력 검증을 대신하지 못한다.

어떤 값이 가능할까?

spellcheck는 열거형 속성이다. 표준이 정의한 키워드는 true와 false 두 가지다.

• spellcheck="true": 맞춤법과 문법 검사를 허용한다.
• spellcheck="false": 맞춤법과 문법 검사를 비활성화한다.
• 속성을 생략하면 기본 상태가 적용된다.

중요한 점은 생략이 항상 "켜짐"을 뜻하지 않는다는 것이다. 표준은 요소마다 기본 동작을 true-by-default, false-by-default, inherit-by-default 가운데 하나로 둘 수 있게 정의한다.

어디에 적용할 수 있을까?

표준은 검사 대상이 될 수 있는 텍스트를 세 부류로 본다. 첫째는 수정 가능한 textarea, 둘째는 수정 가능한 input 중 text, search, url, email 상태, 셋째는 contenteditable 같은 편집 호스트 안의 텍스트다.

즉 비밀번호 입력처럼 민감한 필드나 읽기 전용 필드는 같은 범주로 다루지 않는다. 사용 기준도 여기서 갈린다. 일반 문장 입력란에는 켜 두는 편이 자연스럽고, 코드 조각이나 제품 키처럼 사전 기반 교정이 오히려 방해가 되는 필드에는 끄는 편이 안전하다.

상위 요소에 지정하면 하위에도 적용될까?

그럴 수 있다. 표준 알고리즘은 현재 요소에 spellcheck가 없으면 가장 가까운 조상 요소의 명시적 값을 확인하도록 정의한다. 그래서 편집 영역 전체를 감싸는 컨테이너에 한 번만 지정해도 하위 편집 요소가 그 영향을 받을 수 있다.

다만 하위 요소가 직접 spellcheck="false" 또는 spellcheck="true"를 가지면 그 값이 우선한다. 여러 위젯이 섞인 편집 화면이라면 전역 기본값을 상위에 두고 예외 필드만 개별적으로 덮어쓰는 방식이 가장 읽기 쉽다.

기본값만 믿어도 될까?

여기서 가장 조심해야 한다. 표준은 기본 동작 개념을 정의하지만, 실제 사용자가 브라우저나 운영체제 설정에서 검사 기능을 강제로 끄거나 켤 수 있다고 함께 설명한다. 또 element.spellcheck IDL 속성은 이런 사용자 선호를 반영하지 않을 수 있다.

즉 DOM에서 element.spellcheck가 true로 보여도, 실제 화면에서 맞춤법 표시가 나타나지 않을 수 있다. 반대로 사용자가 보조 기능을 통해 검사 동작을 강제할 수도 있다. 실무에서는 "브라우저 UI를 통제한다"가 아니라 "의도를 전달한다"로 이해하는 편이 정확하다.

 

 

어떤 경우에 false가 적합할까?

대부분의 일반 텍스트 입력란에서는 기본값이나 true가 무난하다. 하지만 아래와 같은 필드는 false를 검토할 이유가 분명하다.

• 소스 코드, 명령어, SQL, 정규식처럼 자연어가 아닌 텍스트를 입력하는 필드
• 사용자명, 상품 코드, 추적 번호처럼 사전 기반 교정이 오히려 오입력을 만들 수 있는 필드
• 사내 용어, 브랜드명, 약어가 많아서 빨간 밑줄이 과도하게 늘어나는 편집 화면

이 경우에도 입력 검증은 별도 규칙으로 처리해야 한다. spellcheck는 표시 제어용이지 형식 검사용 속성이 아니다.

lang 속성과 함께 봐야 하는 이유

표준은 사용자 에이전트가 어떤 맞춤법 규칙을 적용할지 결정할 때 요소의 언어 정보나 사용자의 선호 언어를 참고할 수 있다고 설명한다. 그래서 다국어 편집 UI에서는 spellcheck만 맞게 두고 lang을 비워두면 기대와 다른 사전이 적용될 수 있다.

예를 들어 한국어 입력 필드와 영어 입력 필드가 섞여 있다면, 맞춤법 표시 자체를 켤지 끌지만 볼 것이 아니라 각 필드의 lang까지 분리하는 편이 더 안정적이다.

권장 패턴은 무엇일까?

• 일반 문장 입력란: 기본값을 유지하거나 spellcheck="true"를 명시한다.
• 코드, 식별자, 토큰 입력란: spellcheck="false"를 우선 검토한다.
• 복합 편집기: 상위 편집 영역에 기본값을 주고 예외 필드만 하위에서 덮어쓴다.
• 다국어 폼: spellcheck와 함께 lang를 같이 점검한다.

예시

<label>
  댓글
  <textarea spellcheck="true" lang="ko"></textarea>
</label>

<label>
  Git branch 이름
  <input type="text" spellcheck="false" autocapitalize="off" autocorrect="off">
</label>

<div contenteditable="true" spellcheck="true">
  <p>일반 설명 문장</p>
  <code spellcheck="false">npm run build</code>
</div>

핵심은 입력 성격에 맞춰 자연어 영역과 식별자 영역을 나누는 것이다. 모든 필드에 일괄적으로 끄거나 켜는 방식은 대개 불필요한 마찰을 만든다.

FAQ

Q. spellcheck를 생략하면 항상 켜질까?

아니다. 표준은 생략 시 기본 상태가 적용된다고 정의하며, 그 기본 동작은 요소 종류와 조상 요소의 값에 따라 달라질 수 있다.

Q. spellcheck="true"면 입력 검증도 함께 되는가?

아니다. 이 속성은 맞춤법과 문법 표시를 위한 힌트일 뿐이며, 형식 검증은 type, pattern, 서버 검증 같은 별도 규칙이 맡는다.

Q. 스크립트에서 element.spellcheck를 읽으면 실제 사용자 화면 상태를 알 수 있을까?

완전히 그렇지는 않다. 표준은 이 IDL 속성이 사용자 선호 설정으로 인한 실제 검사 상태를 반영하지 않을 수 있다고 설명한다.

정리

spellcheck는 브라우저의 맞춤법 표시를 완전히 보장하는 스위치가 아니라, 편집 가능한 텍스트에 대한 의도를 전달하는 전역 속성이다. 2026년 7월 26일 확인 기준 WHATWG HTML 표준은 이 속성이 상속형 기본값, 사용자 선호 설정, 입력 종류에 따라 함께 해석된다고 설명한다.

실무 기준은 단순하다. 자연어 문장을 쓰는 입력란은 기본값 또는 true, 코드나 식별자를 쓰는 입력란은 false를 우선 검토하면 된다. 그리고 다국어 환경이라면 lang까지 함께 지정하는 편이 더 예측 가능하다.

참고 자료

• WHATWG HTML Living Standard: Spelling and grammar checking