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
- Abra a página exatamente no navegador, no perfil e no dispositivo que você quer conhecer. As verificações começam sozinhas.
- Leia a contagem do resumo e depois percorra cada grupo procurando as linhas marcadas como não suportadas.
- No grupo de mídia, repare em qualquer codec marcado como parcial. É o navegador respondendo maybe em vez de probably.
- Clique no botão de copiar como texto para levar a lista inteira para a área de transferência.
- 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.