HTML autocapitalize 속성 기준 정리

HTML autocapitalize 속성 기준 정리

autocapitalize는 모바일 가상 키보드나 음성 입력처럼 자동 대문자 전환이 개입하는 입력 방식에서, 문장 단위로 대문자를 넣을지, 단어별로 넣을지, 아예 끌지를 정하는 HTML 속성이다. 2026년 7월 22일 기준 WHATWG HTML Living Standard를 보면 이 속성은 input, textarea, contenteditable 편집 영역, 그리고 관련 폼의 기본값 제어에 사용된다.

실무에서 핵심은 세 가지다. 기본 동작에 기대지 말고 필요한 입력 필드에서 명시할 것, email·url·password에는 효과가 없다는 점을 이해할 것, 그리고 이 속성을 입력 검증 수단으로 오해하지 않을 것이다. 이 글은 스펙 기준으로 값의 의미와 안전한 사용 기준만 짧게 정리한다.

autocapitalize는 무엇을 제어할까?

스펙은 이 속성이 주로 모바일 가상 키보드와 음성 입력의 자동 대문자 처리에 관여한다고 설명한다. 반대로 물리 키보드 입력에는 일반적으로 영향을 주지 않는다. 따라서 데스크톱에서 테스트했을 때 변화가 없어 보여도 속성이 무의미하다고 단정하면 안 된다.

또한 사용자가 동작을 덮어쓰거나 입력 후 텍스트를 다시 수정할 수 있으므로, 스펙은 autocapitalize를 어떤 형태의 입력 검증에도 의존해서는 안 된다고 못 박는다.

값은 어떻게 해석될까?

값	의미	실무 해석
none 또는 off	자동 대문자 적용 안 함	식별자, 코드, 소문자 보존이 중요한 입력에 적합
sentences 또는 on	문장 첫 글자를 대문자로 시작	일반적인 자유 입력 문장에 무난
words	단어 첫 글자를 대문자로 시작	영문 이름이나 제목 입력처럼 단어 단위 구분이 필요한 경우에 검토
characters	모든 글자를 대문자로 시작	약어, 코드, 대문자 식별자 입력처럼 의도가 분명할 때만 사용

WHATWG 스펙상 속성이 없으면 기본 상태는 Default다. 이 상태는 브라우저와 입력 수단이 스스로 동작을 정한다는 뜻이다. 즉 결과가 구현체에 맡겨지므로, 입력 경험이 중요하다면 값을 명시하는 편이 안전하다.

잘못된 값을 넣었을 때의 스펙 기본값은 sentences다. 오타가 난 속성값을 브라우저가 조용히 문장 단위 자동 대문자로 해석할 수 있다는 뜻이므로, 템플릿이나 컴포넌트에서 값 유효성을 함께 관리하는 편이 낫다.

어디에 둘 수 있을까?

이 속성은 input, textarea, 편집 호스트, 그리고 form에 둘 수 있다. 특히 폼에 지정하면 해당 폼과 연결된 자동 대문자 상속 대상 요소들의 기본값을 한 번에 정할 수 있다.

스펙의 계산 규칙을 보면 개별 input이나 textarea에 값이 없고 폼 소유자가 있으면 폼의 값을 따른다. 반대로 필드 자체에 속성을 지정하면 그 값이 우선한다. 여러 입력 필드에 같은 기준을 적용해야 할 때 폼 단위 선언이 유용한 이유가 여기에 있다.

효과가 없는 입력 타입은 무엇일까?

input type="url", input type="email", input type="password"에는 이 속성이 자동 대문자 사용을 켜지 않는다. 스펙의 used autocapitalization hint 알고리즘이 이 세 타입에서 Default를 반환하도록 정의하기 때문이다.

실무적으로도 이 동작은 타당하다. URL, 이메일, 비밀번호는 대소문자 보존이나 오입력 방지가 더 중요하므로, 자동 대문자 개입이 오히려 혼란을 만들 수 있다.

언제 어떤 값을 고르는 편이 무난할까?

입력 종류	권장값	이유
검색어, 사용자 ID, 코드 조각	none	의도치 않은 대문자 전환을 피하는 편이 안전함
일반 문장형 메모, 문의 내용	sentences	자연어 입력 편의성과 예측 가능성의 균형이 좋음
영문 이름, 제목 스타일 입력	words	단어 경계마다 대문자 시작이 필요한 경우가 있음
항상 대문자여야 하는 짧은 코드	characters	입력 후 후처리보다 처음부터 대문자 유도가 단순함

무난한 기본 원칙은 자연어 문장은 sentences, 기계가 읽는 값이나 식별자는 none이다. 이 기준만 지켜도 대부분의 입력 UX 실수는 피할 수 있다.

예시로 보면 더 분명하다

<form autocapitalize="sentences">
  <label>
    메모
    <textarea name="memo"></textarea>
  </label>

  <label>
    사용자 ID
    <input type="text" name="userId" autocapitalize="none">
  </label>

  <label>
    이메일
    <input type="email" name="email" autocapitalize="words">
  </label>
</form>

이 예시에서 메모는 폼의 sentences를 따른다. 사용자 ID는 필드 자체의 none이 우선한다. 이메일 필드는 속성값을 써도 스펙상 자동 대문자 활성화 대상이 아니므로, 기대한 효과가 보장되지 않는다.

자주 헷갈리는 질문

Q. placeholder나 value의 대소문자도 자동으로 바뀔까?

아니다. 이 속성은 사용자가 텍스트를 입력하는 과정의 자동 대문자 힌트를 제어한다. 기존 문자열 자체를 변환하는 기능으로 정의되어 있지 않다.

Q. 브라우저가 항상 이 값을 그대로 따라야 할까?

그렇지 않다. 스펙은 사용자 에이전트나 입력 수단이 특정 상황에서 used autocapitalization hint를 무시하거나 덮어쓸 수 있다고 설명한다. 따라서 이 속성은 강제 규칙이라기보다 권장 힌트에 가깝다.

Q. 서버 검증을 대신할 수 있을까?

할 수 없다. 스펙은 물리 키보드 입력에 보통 영향을 주지 않고, 사용자가 동작을 바꾸거나 사후 수정할 수도 있으므로 입력 검증에 의존해서는 안 된다고 명시한다.

정리

autocapitalize는 모바일 중심 입력 경험을 다듬는 힌트 속성이다. 중요한 기준은 "자연어 입력인가, 식별자 입력인가"다. 자연어 문장은 sentences, 식별자와 코드성 입력은 none이 대체로 무난하다.

또한 2026년 7월 22일 기준 WHATWG HTML Living Standard에서는 기본 상태를 브라우저 판단에 맡기고, email·url·password에는 자동 대문자 활성화를 허용하지 않는다. 따라서 동작을 기대한다면 값을 명시하되, 검증은 별도 로직으로 처리하는 편이 맞다.

참고 자료

• WHATWG HTML Living Standard: Autocapitalization