HTML autocorrect 속성 기준 정리

HTML autocorrect 속성 기준 정리

autocorrect는 브라우저나 입력기가 텍스트 입력 중 맞춤법 자동 수정 기능을 써도 되는지 제어하는 HTML 속성이다. 2026년 7월 24일 기준 WHATWG HTML Living Standard를 보면 이 속성은 input, textarea, 편집 가능한 영역, 그리고 form의 기본 동작을 조절하는 용도로 정의되어 있다.

실무에서 핵심은 세 가지다. 어떤 요소에 적용되는지, 기본값이 무엇인지, 그리고 모든 입력칸에서 강제로 켜지거나 꺼지는 것이 아니라는 점이다. 특히 URL, email, password 계열 입력은 autocorrect="on"을 적어도 자동 수정이 활성화되지 않는다.

autocorrect는 무엇을 제어할까?

이 속성은 사용자가 텍스트를 입력할 때 브라우저나 입력기가 철자 보정 같은 자동 수정 기능을 허용할지 결정하는 힌트다. 표준은 자동 수정이 공백, 줄바꿈, 문장부호 입력 시점에 함께 일어날 수 있다고 설명한다.

중요한 점은 이 속성이 자동 수정을 반드시 수행하라고 강제하지는 않는다는 것이다. 실제 자동 수정 여부와 UI는 사용자 에이전트와 사용자 설정에 따라 달라질 수 있다. 따라서 서비스가 이 속성만으로 입력 결과를 완전히 통제할 수 있다고 보면 안 된다.

어디에 적용할 수 있을까?

대상	의미	실무 판단
input	텍스트 입력 계열에서 자동 수정 허용 여부를 지정	이름, 검색어, 일반 텍스트처럼 오타 보정이 유용한 경우 검토
textarea	여러 줄 텍스트 입력의 자동 수정 허용 여부를 지정	메모, 댓글, 설명 입력에서 기본값을 명확히 할 때 유용
편집 가능한 영역	contenteditable 같은 editing host의 자동 수정 동작 제어	에디터 UI에서 입력 보정을 허용할지 별도로 판단
form	연결된 하위 입력 요소의 기본값 제공	폼 전체 정책을 먼저 정하고 일부 필드만 예외 처리할 때 적합

표준은 form에 지정한 값이 연관된 입력 요소의 기본값으로 쓰일 수 있다고 정의한다. 그래서 회원가입 폼처럼 입력칸이 많은 화면에서는 폼에 기본 정책을 두고, 일부 필드에만 개별 속성을 덮어쓰는 방식이 깔끔하다.

값은 무엇을 쓸 수 있을까?

autocorrect는 열거형 속성이다. 표준이 정의한 키워드는 on과 off 두 가지뿐이다.

값	의미	기준
on	자동 수정이 허용될 수 있음	자연어 입력, 검색, 메모처럼 오타 보정 이점이 클 때
off	자동 수정이 허용되지 않음	식별자, 코드, 명령어, 상품 코드처럼 원문 보존이 중요할 때

누락값 기본값, 빈 문자열 기본값, 잘못된 값 기본값은 모두 on 상태다. 즉 속성을 빼거나 잘못 적었다고 해서 자동으로 off가 되는 구조는 아니다.

어떤 입력에서는 on이어도 동작하지 않을까?

WHATWG 표준은 type="url", type="email", type="password"인 input 요소에서는 autocorrect가 자동 수정을 활성화하지 않는다고 명시한다. 이 예외는 사용된 autocorrection state 계산에도 그대로 들어간다.

실무적으로는 주소, 이메일, 비밀번호는 사용자가 입력한 문자열을 그대로 보존하는 편이 더 중요하다는 뜻으로 받아들이면 된다. 이런 필드에 autocorrect="on"을 넣어도 기대한 효과를 전제로 설계하면 안 된다.

form에 두는 값은 어떻게 상속될까?

표준 알고리즘에 따르면 요소 자체에 autocorrect 속성이 있으면 그 값을 먼저 쓴다. 해당 속성이 없고, 요소가 상속 대상이며 form owner가 있으면 그 폼의 autocorrect 상태를 따른다. 둘 다 없으면 기본적으로 on이다.

예를 들어 검색 폼 전체를 off로 두고, 자유 서술형 textarea 하나만 on으로 예외 처리할 수 있다. 반대로 폼 전체를 on으로 두고 제품 코드나 계정 ID 입력칸만 off로 막는 방식도 가능하다.

어떤 경우에 off가 무난할까?

입력 종류	권장 판단	이유
코드, CLI 명령어	off	한 글자 수정도 동작 오류로 이어질 수 있음
상품 코드, 사번, 고객 번호	off	사전 기반 보정이 식별자를 바꿀 수 있음
검색어, 메모, 일반 문장	on 검토	입력 편의가 더 중요한 경우가 많음
리치 텍스트 에디터	기능별 별도 판단	브라우저 동작과 에디터 스크립트가 함께 작동할 수 있음

대부분의 서비스에서는 "자연어 입력이면 on, 식별자 입력이면 off" 정도의 기준이 실용적이다. 다만 운영 화면에서 실제 입력 언어와 사용자 기기 조합이 다르면 최종 UX는 테스트로 확인하는 편이 맞다.

autocapitalize, autocomplete와는 무엇이 다를까?

autocorrect는 오타 보정 허용 여부를 다룬다. 반면 autocapitalize는 자동 대문자 처리 힌트이고, autocomplete는 과거 입력값이나 의미 기반 자동 완성 힌트다. 이름이 비슷해 보여도 제어 대상이 다르다.

폼 입력 UX를 다듬을 때는 이 세 속성을 함께 보되, 각자 해결하는 문제가 다르다는 점을 분리해서 생각해야 한다. 예를 들어 이메일 입력은 autocomplete="email"은 유용할 수 있지만, 자동 수정은 기본적으로 비활성 예외에 해당한다.

자주 묻는 질문

Q. autocorrect="off"면 모든 기기에서 오타 보정이 완전히 사라질까?

표준은 이 속성을 자동 수정 허용 여부를 제어하는 장치로 정의하지만, 실제 동작과 UI는 사용자 에이전트와 사용자 설정에 달려 있다. 따라서 절대적인 보장을 전제로 설계하기보다, 주요 대상 브라우저에서 확인하는 편이 안전하다.

Q. form autocorrect="off"만 두면 모든 입력칸에 충분할까?

기본 정책으로는 충분할 수 있지만, 일부 필드는 요소 자체 속성으로 예외 처리해야 할 수 있다. 표준 알고리즘은 요소의 명시 값이 있으면 그것을 우선한다.

Q. 이메일 입력에 autocorrect="on"을 넣어도 도움이 될까?

표준 기준으로는 그렇지 않다. type="email" 입력은 autocorrect로 자동 수정이 켜지지 않는 예외다.

정리

autocorrect는 텍스트 입력의 자동 수정 허용 여부를 지정하는 속성이다. 기본값은 사실상 on 쪽에 가깝고, 요소 값이 없으면 form 값이 상속될 수 있다.

실무 기준으로는 자연어 입력에서는 on을 검토하고, 코드·식별자·명령어처럼 원문 보존이 중요한 필드는 off를 우선 검토하면 된다. 그리고 URL, email, password 계열 입력은 예외라는 점을 따로 기억해 두는 편이 안전하다.

참고 자료

• WHATWG HTML Living Standard: Autocorrection
• WHATWG HTML Living Standard: Autocapitalization