Por que o iPhone dá zoom na página quando toco num campo do formulário?

O Safari do iPhone amplia a página inteira quando você toca num campo de texto cuja fonte é menor que 16 pixels, e na minha experiência não desfaz esse zoom sozinho ao sair do campo. A correção é deixar o campo com 16px ou mais no celular. Desligar o zoom da página não resolve e prejudica quem precisa ampliar. Esse limite de 16px eu medi, mas não encontrei documentado pela Apple, e explico abaixo o que conferi.

O que a documentação diz

Conferi em 10 de outubro de 2026. O guia da Apple sobre o viewport (a área da tela que o navegador usa para desenhar a página) explica as opções user-scalable, minimum-scale e maximum-scale do meta viewport. Ele não menciona zoom ao focar um campo de formulário nem o número 16. Procurei também no código-fonte do WebKit, o motor do Safari, e não achei esse limite explicado em texto. Então a regra dos 16px, para mim, é comportamento observado e não contrato documentado. Pode mudar sem aviso, e vale testar num aparelho real.

Sobre a saída que muita gente tenta, a MDN avisa que user-scalable=no impede quem tem baixa visão de ler a página, e que a recomendação é permitir ampliação de até 5 vezes. A MDN também diz que o iOS 10 ou mais novo ignora essa regra por padrão. Ou seja, desligar o zoom estraga a acessibilidade e nem funciona no iPhone.

O que vi em produção

Num projeto em que trabalhei, medi o problema no WebKit, com um iPhone 17 Pro emulado e a versão de produção. O Chrome do Android não amplia a página, mas campos tão pequenos ficam ilegíveis do mesmo jeito, então a correção serve aos dois. Medi de duas formas:

• Abrindo as telas e lendo o tamanho de fonte de cada campo, achei 15 campos abaixo de 16px.
• Procurando no código-fonte inteiro, achei 143 campos escritos à mão, com fontes de 10px a 15px, espalhados por cerca de 40 arquivos.

A diferença entre 15 e 143 tem uma explicação simples. Uma varredura de tela só enxerga o que está aberto naquele instante. O código mostra tudo. O campo do componente compartilhado do projeto não definia tamanho e herdava 16px, então nunca tinha o defeito. Todos os 143 eram campos feitos direto nas telas.

Teve ainda uma armadilha de organização. A escala de tamanhos de fonte do projeto reservava o degrau de 15px para "corpo destacado, campo e título de cartão". Ou seja, quem seguia a escala direitinho criava um campo que dava zoom no iPhone.

Por que acontece

Não sei o motivo interno do Safari e a Apple não explica. O que dá para dizer é o efeito: o navegador amplia a página para deixar o campo legível quando a fonte é pequena, e o usuário fica com a tela ampliada e o formulário cortado. O tamanho que conta é o calculado no navegador, depois de todas as regras de CSS aplicadas, e não o que você escreveu num arquivo.

O que fazer

1. Em vez de corrigir 143 campos um a um, escreva uma regra única que vale para todos. Campo escrito à mão amanhã nasce com o mesmo defeito, e o remendo individual não protege contra ele.

@media (max-width: 767px) {
  input:not([type='checkbox']):not([type='radio']):not([type='range']):not([type='color']),
  select,
  textarea {
    font-size: 16px !important;
  }
}

2. O !important foi necessário no meu caso, porque a classe de tamanho do Tailwind (como text-sm) vence um seletor de elemento na cascata do CSS. Se você não usa uma biblioteca assim, talvez dê para dispensar.
3. Limite a regra às telas pequenas. Assim o desktop mantém a densidade que já tinha.
4. Se o seu design system define um degrau de fonte para campo, conserte o degrau na origem, para a escala deixar de recomendar o defeito.
5. Prove a correção medindo, não olhando. Injete campos com cada classe real da página e leia o font-size calculado. Isso cobre as telas que exigem login e que uma varredura não alcança.
6. Teste no motor WebKit, de preferência num iPhone de verdade, porque emulação mede geometria e não abre o teclado.

Um problema vizinho: com o teclado aberto, o Safari rola a tela para manter o campo visível, e não o botão logo abaixo. O botão "Entrar" some atrás do teclado. Um scroll-margin-bottom no campo reduz isso, e usei 96px. Não consegui verificar esse ponto em emulação, porque ela mede geometria e não abre o teclado.

Se o seu aplicativo web ou PWA tem defeitos de acabamento só em celular, conheça como eu trabalho em aplicativos.