# Recursos do navegador

Assim que esta página abre, ela testa cerca de 60 recursos da plataforma web no navegador que você está usando e marca cada um como suportado ou não. Nenhum pedido de permissão aparece e nada é enviado a lugar nenhum.

## Resposta curta

Esta página roda 61 testes de recursos no seu próprio navegador, em nove grupos (JavaScript, CSS, gráficos, mídia, armazenamento, rede, APIs de dispositivo, interface e segurança), e marca cada um como suportado, parcialmente suportado ou ausente. Um teste confirma que o recurso existe, por meio de um objeto, de um método, de `CSS.supports()` ou de `canPlayType()`; ele não prova que o recurso funciona sem bugs.

### Como é obtido

Cada linha é uma verificação de detecção de recursos executada quando a página carrega, a técnica que o MDN recomenda em vez de ler o User-Agent. JavaScript e APIs da web são testados procurando o objeto ou o método; CSS, perguntando a `CSS.supports()` se uma declaração ou um seletor é entendido; gráficos, criando um canvas novo para cada tipo de contexto; mídia, com `canPlayType()`, em que a resposta “probably” conta como Sim e “maybe” como Parcial. A lista pode ser copiada como texto simples.

### Exemplo prático

`CSS.supports("container-type: inline-size")` retorna `true` num navegador que implementa consultas de contêiner, então essa linha mostra Sim. Para vídeo AV1, a página pergunta `canPlayType('video/mp4; codecs="av01.0.05M.08"')`; um navegador que responde “maybe” aparece como Parcial, porque ainda pode falhar ao decodificar esse perfil.

### Limites

- Um recurso pode existir e mesmo assim estar desativado por uma política, por uma permissão ou pelo hardware.
- Algumas APIs só aparecem em páginas seguras (HTTPS) ou depois de um gesto do usuário.
- Os resultados descrevem este navegador, neste dispositivo, hoje; outro dispositivo ou outra versão pode dar resultado diferente.

### Fontes

- [MDN: Implementing feature detection](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Testing/Feature_detection): por que testar recursos em vez de navegadores.
- [CSS Conditional Rules Module Level 3](https://www.w3.org/TR/css-conditional-3/): o método CSS.supports().
- [HTML Standard: canPlayType()](https://html.spec.whatwg.org/multipage/media.html#dom-navigator-canplaytype): o significado de “probably” e “maybe”.
- [web.dev: Baseline](https://web.dev/baseline): quais recursos todos os principais navegadores suportam.

## O que a ferramenta faz

Quando esta página abre, um script roda cerca de 60 pequenas verificações no navegador que você está usando e lista cada recurso como suportado ou não. Os resultados ficam agrupados em linguagem JavaScript, CSS, gráficos, mídia e codecs, armazenamento, rede, APIs de dispositivo, segurança e recursos de interface, com a contagem de recursos suportados no resumo lá em cima.

Cada verificação é uma pergunta que o navegador consegue responder sem fazer nada visível. No JavaScript, isso geralmente significa testar se algo existe, como `structuredClone` ou `Promise.withResolvers`, ou se uma sintaxe mais nova é aceita, como uma expressão regular com a flag `v`. As linhas de CSS passam por `CSS.supports()`, que informa se o mecanismo de estilos entende uma propriedade, um valor ou um seletor como `:has()`. As linhas de codecs usam as respostas do próprio navegador em `canPlayType()` e verificações de Media Source.

Nenhuma verificação abre um pedido de permissão, inicia um seletor de dispositivos ou envia algo pela rede. Para APIs de hardware como Web Bluetooth, WebUSB ou Web NFC, suportado quer dizer que o navegador expõe a interface, não que haja um dispositivo conectado ou autorizado.

## Como usar

1. Abra a página exatamente no navegador, no perfil e no dispositivo que você quer conhecer. As verificações começam sozinhas.
2. Leia a contagem do resumo e depois percorra cada grupo procurando as linhas marcadas como não suportadas.
3. No grupo de mídia, repare em qualquer codec marcado como parcial. É o navegador respondendo maybe em vez de probably.
4. Clique no botão de copiar como texto para levar a lista inteira para a área de transferência.
5. Cole no relatório de bug, no chamado ou na conversa, e acrescente a versão do navegador e o sistema operacional se eles ainda não estiverem lá.

Teste na mesma janela em que o problema acontece. Extensões, políticas corporativas e flags experimentais podem ligar ou desligar recursos individuais.

Duas linhas descrevem a página tanto quanto o navegador: contexto seguro depende de como a página foi carregada, e isolamento cross-origin, dos cabeçalhos que o servidor envia; por isso outro site pode receber respostas diferentes nessas duas.

## Casos de uso

- **Chamados de suporte.** Um cliente diz que salvar um arquivo grande não faz nada. Peça que ele abra esta página e cole a lista copiada; uma linha de Origin Private File System ou de Fetch com streams ausente pode resolver a questão numa única resposta.
- **Vídeo que não toca.** Um clipe toca num notebook e mostra só uma tela preta em outro. Compare as linhas de HEVC e AV1 nos dois; um “não” ou um “parcial” é sinal de que vale servir também uma versão em H.264 ou VP9.
- **Decidir o que colocar no ar.** Antes de depender de `:has()`, de consultas de contêiner ou de aninhamento de CSS, abra a página nos navegadores mais antigos que seus usuários ainda usam, incluindo totens e smart TVs.
- **Navegadores dentro de apps.** Links tocados dentro de apps de mensagens e de redes sociais muitas vezes abrem numa visualização web embutida. Abrir esta página desse jeito mostra o que essa visualização suporta, o que pode ser diferente do Safari ou do Chrome no mesmo celular.
- **Projetos de hardware.** Antes de dizer aos usuários que eles podem gravar um microcontrolador ou configurar um teclado por uma página web, peça que confiram as linhas de Web Serial, WebUSB e WebHID; alguns dos principais navegadores simplesmente não têm essas interfaces.

## Detecção de recursos versus leitura do user agent

O hábito antigo era ler a string de user agent e deduzir as capacidades pelo nome do navegador. Isso falha de jeitos previsíveis. Navegadores baseados em Chromium compartilham a maior parte do texto do user agent. O Chrome no iPhone traz o token `CriOS`, mas normalmente renderiza com WebKit, então na maioria das linhas daqui ele se comporta como o Safari. O Chrome também congelou parte dos detalhes de versão e de plataforma na string, e qualquer pessoa consegue mudar a string com poucos cliques.

A detecção de recursos pergunta direto ao navegador que está rodando, o que também simplifica o aprimoramento progressivo: monte uma base que funcione em todo lugar e acrescente o caminho melhor só onde a verificação passar.

```
if ('share' in navigator) {
  shareButton.hidden = false;    // compartilhamento nativo do sistema
} else {
  copyLinkButton.hidden = false; // alternativa simples
}
```

```
@supports (container-type: inline-size) {
  .card-list { container-type: inline-size; }
}
```

Com codecs é igual. Um player pode chamar `video.canPlayType('video/mp4; codecs="av01.0.05M.08"')` e recorrer a uma fonte H.264 quando a resposta for uma string vazia, que é o jeito de o navegador dizer não. As únicas outras respostas possíveis são maybe e probably.

## Por que o mesmo navegador pode responder diferente

### Hardware e sistema operacional

Muitas linhas dependem de mais do que a compilação do navegador. A reprodução de HEVC muitas vezes precisa de um decodificador de hardware ou de suporte a codec no sistema operacional, então a mesma versão do navegador pode discordar em dois notebooks. O Safari informa suporte a AV1 só em aparelhos Apple com decodificador de AV1 em hardware. O WebGPU chegou a alguns sistemas operacionais antes de outros, e um navegador pode desligar o WebGL quando o driver gráfico está na lista de bloqueio. Algumas compilações de navegadores de código aberto deixam de fora codecs licenciados, como H.264 e AAC.

### Contextos seguros

Muitas APIs só existem num contexto seguro: páginas servidas por https, além de endereços locais como `http://localhost` e `http://127.0.0.1`. Service Workers, a API assíncrona da área de transferência, Web Authentication, Web Share, Screen Wake Lock, WebGPU e as APIs de dispositivo estão nesse grupo. Carregue o mesmo site por http simples num endereço da rede local e esses objetos ficam ausentes, e não bloqueados; assim, um recurso que funciona no localhost pode sumir num servidor de testes. `window.isSecureContext` informa o estado. O isolamento cross-origin, que libera o `SharedArrayBuffer`, também exige os cabeçalhos de resposta `Cross-Origin-Opener-Policy` e `Cross-Origin-Embedder-Policy`.

### A lista também é uma impressão digital

Como os resultados variam por navegador, versão, sistema operacional e hardware, o padrão completo de respostas ajuda a descobrir qual configuração um visitante tem. Scripts de impressão digital (fingerprinting) rodam o mesmo tipo de verificação justamente por isso, ao lado da renderização em canvas e das fontes instaladas. Esta página roda as verificações localmente e não envia nada, e o iseeu.cc não guarda registros de endereços IP nem de consultas, mas qualquer site pode rodar um código equivalente sem mostrar o resultado a você. Antes de colar a lista num sistema público de acompanhamento de problemas, trate-a como qualquer outro detalhe do seu sistema que você compartilha.

## Perguntas frequentes

**Esta página pede permissão de câmera, Bluetooth ou notificações?**

Não. Cada verificação só pergunta se uma API existe ou se o navegador diz suportar algo. Nada chama um método que abriria um pedido de permissão ou um seletor de dispositivos, e nenhum dado sai do seu navegador. A linha de notificações, por exemplo, confere se a API está presente; ela não pede para mostrar notificações a você. Além disso, o iseeu.cc não usa cookies e não guarda registros de endereços IP nem de consultas.

**Aparece como suportado, mas não funciona no meu site. Por quê?**

Suportado, aqui, quer dizer que o navegador expõe a API ou diz entender a sintaxe. O uso real ainda pode falhar: seu site pode estar carregando por http simples e perder as APIs de contexto seguro, uma permissão pode ter sido negada, uma política pode bloquear um dispositivo ou o WebGPU pode não encontrar um adaptador gráfico utilizável. As linhas de codecs refletem o que o navegador afirma, e um perfil ou uma resolução incomum ainda pode falhar na decodificação.

**O que significa “parcial” nas linhas de codecs?**

O método canPlayType nunca responde sim. Ele devolve probably quando o navegador está bastante confiante de que consegue reproduzir o formato, maybe quando reconhece o formato mas não tem como ter certeza sem tentar, e uma string vazia para não. Esta página mostra maybe como parcial. Trate um resultado parcial como motivo para fazer um teste de reprodução de verdade, com o seu próprio arquivo, antes de depender desse codec.

**Por que meu colega vê resultados diferentes com a mesma versão do navegador?**

Várias linhas dependem do sistema operacional e do hardware, não da versão do navegador. HEVC e AV1 muitas vezes dependem de decodificadores de hardware, a disponibilidade do WebGPU varia conforme a plataforma e o driver gráfico, e algumas compilações vêm sem codecs licenciados. Extensões, políticas corporativas, flags experimentais e janelas anônimas também podem mudar respostas individuais. Comparar lado a lado as duas listas copiadas é o jeito mais rápido de achar a diferença.

**Por que alguns recursos somem quando o site abre em http?**

Os navegadores só expõem muitas APIs mais novas em contextos seguros, ou seja, páginas carregadas por https ou a partir de endereços locais como localhost. Numa página em http simples, objetos como navigator.serviceWorker e navigator.clipboard simplesmente ficam indefinidos. Isso é proposital: essas APIs alcançam dispositivos, credenciais ou código que roda em segundo plano por muito tempo, e uma página sem criptografia pode ser alterada no caminho. Sirva os ambientes de teste por https para ver o mesmo comportamento da produção.

**Dá para me identificar com essa lista?**

Sozinha, uma lista de recursos suportados descreve seu navegador, seu sistema operacional e seu hardware, não você. Combinada com outros sinais, como o tamanho da tela, as fontes instaladas e a saída do canvas, ela contribui para uma impressão digital do navegador que pode ajudar a reconhecer um visitante que volta. Esta página roda os testes localmente e não envia nada, mas outros sites podem rodar os mesmos testes sem avisar; a exposição está na combinação, não nesta lista sozinha.

**Não é melhor olhar o user agent?**

Para decidir se dá para usar um recurso, não. Strings de user agent são compartilhadas entre navegadores baseados em Chromium, têm menos detalhes no Chrome, são fáceis de mudar e enganam no iPhone, onde o Chrome e o Firefox normalmente renderizam com WebKit. Testar o recurso diretamente dá a resposta do navegador que está de fato rodando. A string de user agent continua útil num relatório de bug, para registrar a versão exata do navegador.

A detecção mostra o que o navegador expõe ou afirma. Um recurso ainda pode estar desativado por uma política, pela falta de hardware ou por uma permissão negada quando um site tentar usá-lo de fato.

## Ferramentas relacionadas

- [Impressão digital do navegador](https://iseeu.cc/pt/teste-impressao-digital-navegador/): Os sinais que permitem reconhecer seu navegador sem cookies.
- [Meu user agent](https://iseeu.cc/pt/meu-user-agent/): Veja e analise o User-Agent e os Client Hints que seu navegador envia.
- [Teste de vazamento WebRTC](https://iseeu.cc/pt/teste-vazamento-webrtc/): Veja se o WebRTC expõe um endereço IP que sua VPN deveria esconder.
- [Qual é o meu IP?](https://iseeu.cc/pt/): Seu endereço IP, localização, rede, cabeçalhos, TLS e testes de vazamento em uma só página.
- [Conversor Punycode](https://iseeu.cc/pt/conversor-punycode/): Converte domínios com acentos ou outros alfabetos para a forma xn-- e de volta.

[Ver todas as ferramentas](https://iseeu.cc/pt/ferramentas/)

Última atualização: 2026-10-11

Página original: https://iseeu.cc/pt/recursos-navegador/