Imagens Open Graph: tamanhos, formatos e por que a sua não aparece

O padrão 1200×630 e por quê

O padrão de fato og:image tamanho é 1200×630 pixels, uma proporção de aproximadamente 1.91:1. Esse número não é uma tradição arbitrária — ele se aproxima da proporção mais larga usada na maioria dos cartões de prévia de links no Facebook, LinkedIn, Slack e Discord. Isso significa que uma imagem de 1200×630 preenche o cartão sem que a plataforma precise adicionar faixas ou fazer um recorte significativo.

Imagens menores tecnicamente funcionam, mas são ampliadas pela plataforma para preencher o cartão, o que suaviza os detalhes e pode ficar visivelmente pior que uma imagem criada para esse uso. A maioria das plataformas documenta um mínimo de cerca de 200×200 para que a imagem seja aceita como prévia, mas trate isso como um limite mínimo, não uma meta — qualquer tamanho significativamente abaixo de 1200×630 desperdiça qualidade sem benefício.

Do Twitter/X summary_large_image cartão usa a mesma imagem de 1200×630 e a mesma proporção, então uma imagem normalmente atende aos dois og:image e twitter:image sem precisar de uma exportação separada.

Área segura: o que realmente permanece após o recorte

Mesmo com a proporção correta, diferentes plataformas recortam o cartão de formas ligeiramente diferentes conforme o local — uma publicação no feed, uma prévia de link em mensagem direta e um módulo de "links compartilhados" na barra lateral nem sempre usam o mesmo recorte da mesma imagem. Um texto ou logotipo encostado na borda pode ser cortado em um desses locais, mesmo que pareça correto na prévia da sua aba de navegador.

A prática segura é manter o conteúdo essencial — um título, um logotipo, um rosto — dentro dos aproximadamente 90% internos do enquadramento, deixando uma margem de cerca de 5–10% em cada borda. Imagens de fundo, degradês e elementos decorativos podem chegar à sangria total sem problema; apenas o conteúdo que todo espectador precisa ver deve ficar afastado das bordas. Se sua ferramenta de design permitir, desenhar um retângulo-guia recuado cerca de 60px de cada lado de uma tela de 1200×630 dá uma área segura de trabalho razoável.

Formato: JPG ou PNG, e por que não WebP

Para o arquivo de imagem em si, JPG e PNG são as escolhas seguras. O suporte a WebP para og:image especificamente é inconsistente entre os rastreadores e bots que geram prévias de links — alguns o aceitam, outros falham silenciosamente e não renderizam prévia nenhuma quando recebem WebP. Como a falha é silenciosa, é fácil publicar uma prévia quebrada sem perceber até alguém avisar.

Esse requisito de compatibilidade é mais restrito que servir WebP a um navegador, algo que quase todos os navegadores atuais fazem bem — veja nosso Comparação entre WebP, PNG e JPG para o caso geral. Rastreadores de prévias de links são um conjunto de clientes diferente e mais conservador que os navegadores dos usuários, e sua compatibilidade com WebP fica atrás. Use JPG para prévias fotográficas (arquivo menor com qualidade visual equivalente) e PNG quando a imagem tiver cores chapadas, texto ou precisar preservar transparência em alguns contextos — embora a transparência em si não importe em uma imagem OG, já que ela sempre é renderizada sobre o fundo usado pelo cartão da plataforma.

GIF é tecnicamente aceito pela maioria das plataformas como imagem estática, mas não faz sentido para uma prévia fotográfica ou com design elaborado; não há motivo prático para preferi-lo a JPG ou PNG neste caso.

A URL precisa ser absoluta

<meta property="og:image" content="/og-image.jpg" /> parece razoável e funciona bem quando você visualiza a página diretamente no navegador, porque ele resolve o caminho relativo com base na URL da própria página. Rastreadores de prévias de links frequentemente não fazem essa resolução de forma confiável ou usam a base errada — na prática, a imagem fica quebrada ou ausente em algumas plataformas e funciona em outras, tornando o erro difícil de diagnosticar apenas por relatos de usuários.

Sempre informe a URL absoluta completa, incluindo o protocolo e o domínio:

<meta property="og:image" content="https://example.com/og-image.jpg" />

Na API Metadata do Next.js, isso significa definir metadataBase no layout raiz para que caminhos relativos de imagem declarados nos metadados da página sejam convertidos automaticamente em URLs absolutas durante a compilação, ou escrever a URL completa diretamente em cada página, em openGraph.images entrada, como este site faz.

Cache: por que uma imagem corrigida ainda mostra a prévia antiga

Essa é a causa mais comum de "corrigi, mas ainda aparece errado". As plataformas armazenam em cache os dados Open Graph coletados — incluindo a imagem — por URL, e esse cache não expira só porque você publicou um novo arquivo. Recarregar a página por conta própria, mesmo em uma janela privada, não informa nada sobre o que o cache da plataforma ainda contém.

Cada grande plataforma tem sua própria ferramenta para forçar uma nova coleta de dados:

• Facebook / Meta: o Sharing Debugger (developers.facebook.com/tools/debug/) — cole a URL e clique em "Scrape Again". Isso também limpa o cache usado pelas prévias de links do Instagram e WhatsApp, que compartilham o rastreador da Meta.
• X/Twitter: o Card Validator historicamente serviu para isso; a disponibilidade mudou com o tempo, então, se ele estiver inacessível, acrescentar um parâmetro inofensivo de versão à URL (veja abaixo) é a alternativa mais confiável.
• LinkedIn: o Post Inspector (linkedin.com/post-inspector/) — cole a URL para forçar uma nova busca.
• Slack, Discord, iMessage: sem depurador público. Normalmente, elas expiram o próprio cache após algum tempo, conforme seu próprio cronograma, ou atualizam quando a URL muda, mesmo que pouco.

Quando um depurador específico de plataforma não está disponível ou também não coopera, a alternativa universal é mudar a URL que a plataforma vê — acrescentando um parâmetro de versão como ?v=2 ao link compartilhado ou à própria URL da imagem força todas as plataformas a tratá-lo como um recurso novo e buscá-lo novamente, em vez de servir uma entrada antiga do cache.

Tamanho do arquivo e outros limites

A maioria das plataformas documenta um limite de imagem de poucos megabytes — o limite documentado do Facebook historicamente ficou em torno de 8MB, e plataformas que não publicam um número explícito ainda tendem a exceder o tempo limite ou não renderizar a prévia de um arquivo grande demais. Como um JPG ou PNG de 1200×630 bem comprimido para esse tipo de conteúdo normalmente fica bem abaixo de 500KB, atingir o limite na prática quase sempre significa uma exportação não otimizada — uma foto original enorme reduzida na marcação, mas não realmente recodificada nas dimensões menores, ou uma exportação PNG de conteúdo fotográfico em vez de JPG. Consulte nosso guia para reduzir o tamanho de arquivos de imagem para a abordagem geral de reduzir uma exportação sem perda visível de qualidade.

Legibilidade do texto em tamanho de miniatura

Uma imagem OG normalmente é exibida muito menor que seus 1200×630 pixels originais — uma prévia expandida no Slack ou um cartão de feed no celular pode mostrá-la com apenas algumas centenas de pixels de largura. Qualquer texto incorporado à imagem precisa continuar legível após essa redução. Como referência prática, texto de corpo abaixo de aproximadamente 40px na largura original de 1200px tende a ficar borrado e ilegível quando reduzido para posições típicas de feed; títulos que precisam ser legíveis em tamanho de miniatura geralmente devem ser bem maiores — por volta de 60–80px ou mais, em negrito e com forte contraste com o fundo.

Esse também é um motivo para manter a própria imagem simples. Uma composição carregada, com vários textos competindo, pode ser legível em tamanho completo, mas vira ruído visual na escala de um cartão; um único título claro sobre um fundo de alto contraste é lido de forma confiável em todas as áreas em que a imagem aparece.

twitter:card precisa de sua própria declaração

Configuração og:image não é automaticamente suficiente para uma prévia de imagem grande no X/Twitter. O sistema de cartões do Twitter lê seu próprio twitter:card meta tag para decidir o estilo do cartão e, sem ela, alguns clientes do Twitter usam um cartão menor de miniatura, mesmo que um perfeitamente adequado og:image está presente.

Declare explicitamente:

<meta name="twitter:card" content="summary_large_image" />

O Twitter usará como alternativa og:image para a imagem real se twitter:image não for definido separadamente, então normalmente você não precisa duplicar a URL da imagem — mas a própria declaração do tipo de cartão não é opcional se você quiser o layout de imagem grande.

Uma sequência rápida de diagnóstico

1. Confirme que a URL da imagem é absoluta, não relativa, e que abre diretamente em um navegador.
2. Confirme que o formato é JPG ou PNG, não WebP.
3. Confirme que as dimensões são 1200×630 ou próximas disso.
4. Confirmar twitter:card está definido se a prévia especificamente do Twitter/X estiver errada.
5. Execute a ferramenta de depuração da plataforma para forçar uma nova coleta antes de presumir que a correção não funcionou.
6. Se não houver depurador disponível, altere uma string de consulta de versão na URL para invalidar o cache.

Perguntas frequentes