Foto profissional para site: tamanho, peso e o recorte que corta a sua cabeça no celular

O checklist da foto profissional para o site, item por item

Quem procura foto profissional para site quer um número de largura, e a resposta honesta é que ele não existe. Existe uma conta, com duas entradas que quase ninguém publica juntas: a largura em que a foto aparece na tela de quem visita e a densidade dessa tela. Este primeiro bloco é o que fica na sua mão; o resto do artigo desmonta as duas entradas, o recorte que come a sua cabeça no celular e três decisões de carregamento.

Ele vale para qualquer página que você controla: a "sobre mim", a página de um serviço, o cabeçalho de uma proposta publicada na web, a página de equipe de um escritório pequeno (quando o site precisa da equipe inteira, a lógica é a mesma, repetida N vezes).

1. Decida a proporção antes de gerar a foto. Horizontal para o topo de uma página larga, quadrado ou vertical para quando a caixa fica estreita. Recortar depois custa rosto.
2. Meça a largura de exibição no navegador. Abra a página no computador, clique com o botão direito sobre a foto e escolha inspecionar: o navegador informa a largura em pixels. Nenhum tema publica a proporção do próprio bloco, então esse número só existe medido.
3. Multiplique pela densidade da tela. Duas vezes para notebook e monitor recente, três vezes quando a foto ocupa a largura inteira de um celular. É daí que sai a largura do arquivo.
4. Publique uma escada de larguras e declare o slot. Um arquivo por largura real, mais o atributo sizes dizendo qual largura aquele espaço terá em cada faixa de janela. Sem isso, o celular baixa o arquivo do desktop.
5. Escolha o formato e mire num peso medido. WebP está entre os formatos aceitos pela Busca, e um retrato de fundo simples a 960 px ficou em 48,2 KB no meu teste. Se o seu está em 800 KB, o problema é a exportação, não a foto.
6. Se o enquadramento muda no celular, publique duas fontes. Arquivo maior resolve nitidez; ele não resolve enquadramento. Enquadramento tem nome próprio na documentação da plataforma web, direção de arte, e pede o elemento picture.
7. Tire o loading lazy da foto da primeira dobra e deixe a foto no HTML. O retrato do topo costuma ser o maior elemento visível da tela, e adiar o carregamento dele é adiar a página inteira.
8. Escreva o alt e o nome do arquivo, e abra a página num celular de verdade. Os dois primeiros são conteúdo; o terceiro é o único teste que pega o recorte real, na janela real, com a densidade real.

Os itens 2 e 3 são a parte que dá trabalho na primeira vez. A tabela abaixo resolve os dois para as cinco posições em que um retrato costuma aparecer num site pequeno. As larguras de exibição são exemplo típico, não spec: a única que vale para você é a que você mediu.

A largura de exibição não é um número, é uma função da janela

Duas das páginas mais fortes que a busca devolve sobre o assunto publicam números que puxam para lados opostos. A Shopify escreve que "as imagens de tela cheia devem ter, no mínimo, 2500 px de largura". A Squarespace recomenda "arquivos em JPEG ou PNG de no máximo 500 KB por imagem" e até 2 MB por página (as duas consultadas em 03/08/2026). Nenhuma das duas está errada, e a Shopify chega perto quando escreve, na mesma página, que a largura em pixels "depende da área de exibição". Falta o passo seguinte: por quanto multiplicar essa área. Nas cinco páginas que baixei, densidade de tela aparece uma única vez, numa frase da HostGator sobre "a resolução da tela e a densidade de pixels", sem número ao lado.

Largura de arquivo e largura de exibição são coisas diferentes. O arquivo é o que você sobe; a exibição é o espaço que o navegador reserva para ele na página. A ponte entre as duas é a densidade da tela, e essa conta já está inteira no guia da foto na assinatura de e-mail, onde o alvo de exibição era fixo e publicado. Recapitulando: largura de arquivo = largura de exibição x densidade da tela.

O que muda aqui, e é o que nenhuma das cinco páginas que medi escreve, é que no site a largura de exibição não é uma constante: ela é uma função da janela. O mesmo retrato ocupa a tela inteira num celular em pé, metade da tela num tablet deitado e um bloco de 480 px numa coluna de texto no notebook. É para isso que existe o par srcset e sizes.

A documentação de imagens responsivas da MDN descreve o algoritmo em quatro passos: o navegador vê a largura do dispositivo, procura na lista do sizes a primeira condição de mídia verdadeira, lê qual é o slot daquela condição e carrega, do srcset, o arquivo do tamanho do slot ou o primeiro maior. Duas consequências saem daí. O descritor do srcset é w, e ele descreve "o tamanho real da imagem", não o da tela. E, literal: "o navegador ignora tudo depois da primeira condição satisfeita, então tenha cuidado com a ordem de condições".

Agora o achado que inverte a intuição. Premissas declaradas, porque densidade de tela é premissa e não spec de aparelho: um celular com 393 px de largura de layout e densidade 3, e um notebook com a janela em 1.440 px, densidade 2, exibindo o retrato num slot fixo de 480 px. No celular a foto ocupa a largura inteira, então 393 x 3 = 1.179 px de arquivo. No notebook, 480 x 2 = 960 px. O arquivo "do celular" é 23% maior que o do desktop: quem publica uma versão pequena "para mobile" entrega a imagem mais borrada justamente para a tela mais densa.

Colado, o par fica assim (o nome no alt é só exemplo):

<!-- Um arquivo por largura real. O descritor w descreve o arquivo, não a tela. -->
<img
  src="retrato-1200.webp"
  srcset="retrato-600.webp 600w,
          retrato-960.webp 960w,
          retrato-1200.webp 1200w,
          retrato-1800.webp 1800w"
  sizes="(max-width: 640px) 100vw,
         (max-width: 1024px) 50vw,
         480px"
  width="1200" height="800"
  alt="Ana Ribeiro, arquiteta, sentada à mesa de trabalho com plantas impressas"
  fetchpriority="high">

Por que cada linha está ali:

• O srcset é a escada de arquivos, e cada degrau declara a própria largura em pixels. Quatro degraus cobrem bem um site pessoal; dois já são melhores que nenhum.
• O sizes é a única linha do bloco que fala do seu layout: ele declara a largura do slot, não a do arquivo. Até 640 px de janela a foto ocupa 100% da largura, até 1.024 px ocupa metade, acima disso fica fixa em 480 px.
• A ordem do sizes decide: a primeira condição verdadeira vence e o resto é ignorado. No celular de 393 px em densidade 3, o 100vw pede cerca de 1.179 px e o navegador sobe para o degrau de 1200w; no notebook, com slot de 480 px em densidade 2, o pedido é de 960 px e ele fica no de 960w.
• O width e o height evitam o pulo de layout: o navegador reserva a caixa antes de ter o arquivo.
• O fetchpriority alto só entra na foto da primeira dobra, e em uma só. Volto a ele mais abaixo.

Por que 1.920 px "para tudo" é caro, e por que 600 px sai borrado

A tentação é publicar um arquivo grande e não pensar mais no assunto. O custo cresce mais rápido do que parece, porque largura é uma dimensão e imagem tem duas: um arquivo de 960 x 640 px tem 614.400 pixels e o de 1.920 x 1.280 px tem 2.457.600. Dobrar a largura quadruplicou a quantidade de pixels.

O peso não segue a mesma curva, e a tabela abaixo é medição minha: seis retratos gerados pelo próprio produto, redimensionados por largura e codificados em WebP com cwebp, mediana dos seis, em 03/08/2026. O que ela mostra é que dobrar a largura multiplicou o arquivo por cerca de 3, não por 4 nem por 2: na faixa medida, o peso cresce com a largura elevada a aproximadamente 1,5.

A qualidade do codificador é a outra alavanca, e a coluna da direita mostra o preço dela: no mesmo retrato a 960 px, subir de q80 para q90 quase dobra o arquivo por um detalhe que ninguém enxerga numa foto exibida a 480 px.

E o argumento que fecha a discussão não é meu. A documentação do Largest Contentful Paint diz que, se qualquer parte do elemento é cortada ou fica fora da janela, essas partes não contam para o tamanho do elemento; e que, para imagens redimensionadas a partir do tamanho intrínseco, o tamanho reportado é o visível ou o intrínseco, o que for menor. Traduzindo para a sua conta: pixel cortado e pixel excedente viajam pela rede, consomem o plano de dados de quem visita e não compram nem métrica.

O outro lado é igualmente concreto, e é a razão de "comprima tudo" também estragar foto. Um arquivo de 600 px numa exibição de 480 px em tela de densidade 2 tem pouco mais da metade da informação que aquela tela sabe desenhar: ela quer 960 px e recebe 600. "Sai borrado" quase sempre significa "o arquivo é menor que a exibição vezes a densidade".

Sobre formato, a régua oficial é curta. A documentação de imagens do Google lista os formatos aceitos no atributo src: BMP, GIF, JPEG, PNG, WebP, SVG e AVIF. Para retrato, WebP é o padrão razoável hoje, e é nele que os pesos acima foram medidos.

A cabeça cortada no celular: o cover recorta pelo centro

Este é o sintoma que faz a pessoa procurar. No computador o retrato está perfeito; no celular some a testa, ou o queixo, ou metade do rosto sai pela lateral. Não é bug do tema nem culpa da foto: são duas linhas de CSS fazendo o que foram feitas para fazer.

A primeira é o object-fit: cover. A MDN descreve o valor assim, em tradução minha do original em inglês: o conteúdo é dimensionado para manter a proporção enquanto preenche toda a caixa do elemento e, se a proporção do objeto não corresponde à da caixa, o objeto "será cortado para caber". A segunda é o object-position, cujo valor inicial documentado é 50% 50%. O recorte padrão é pelo centro geométrico: o contêiner não sabe onde está a sua cabeça, e não vai perguntar.

Quanto se perde é aritmética simples, e a fórmula vale para qualquer par de proporções. Chame de proporção a largura dividida pela altura, do arquivo e da caixa. Se o arquivo é mais largo que a caixa, sobrevive a fração "proporção da caixa dividida pela proporção do arquivo" da largura; se é mais estreito, sobrevive "proporção do arquivo dividida pela proporção da caixa" da altura. Nos dois casos a perda vem metade de cada lado. Os valores prontos por destino, a partir do arquivo horizontal que o gerador entrega, estão no guia do retrato horizontal; aqui interessa a fórmula, porque o seu contêiner tem a proporção que o seu tema quis.

Repare no que a fórmula diz sobre o eixo do corte, porque é aí que mora a confusão. Não existe "corte de celular": existe corte no eixo em que sobra imagem. Uma faixa larga e baixa no desktop é mais deitada que o arquivo, então come o topo e a base, e a cabeça é a primeira a ir. A mesma faixa no celular fica mais em pé que o arquivo e passa a comer as laterais: se você compôs o retrato com a pessoa num terço, para deixar espaço ao lado do título, é o rosto que sai pela borda. Retrato horizontal composto para site é o pior caso do recorte central, porque ele foi feito para ter conteúdo fora do meio.

A correção cabe em uma linha, e ela é derivada, não copiada de spec. Se a cabeça está a X% da largura e a Y% da altura do arquivo, repetir esses dois números no object-position mantém a cabeça a X% e Y% da caixa, em qualquer proporção:

.retrato-do-topo {
  width: 100%;
  height: 100%;
  object-fit: cover;
  /* A cabeça está a 35% da largura e a 30% da altura do arquivo: repita os dois aqui. */
  object-position: 35% 30%;
}

A regra sai de como a porcentagem funciona na sintaxe de posição da CSS, que a MDN documenta na página de background-position: o ponto a X% da imagem é alinhado com o ponto a X% do contêiner. Confere na conta: numa caixa de 400 x 400 px que recebe um arquivo 3:2 escalado para 600 x 400 px sobram 200 px na horizontal; com object-position 25%, o deslocamento é 200 x 25% = 50 px, e o ponto que estava a 25% da largura da imagem (150 px) cai em 100 px, que é 25% da caixa.

Uma linha resolve enquadramento aproximado. Ela não resolve o caso em que o celular precisa de outra foto, e a MDN separa os dois problemas com nome próprio: mudança de resolução é "vários arquivos de imagem, todas mostrando a mesma coisa mas contendo diferentes números de pixels"; direção de arte é "diferentes imagens para diferentes espaços de alocação", e ela, literal, "pode ser resolvido usando o elemento picture". Arquivo maior nunca conserta enquadramento.

E não adianta planejar o conserto para depois, com script. A MDN explica por quê: "quando o navegador começa a carregar a página, inicia o download de todas as imagens antes do analisador principal ter começado a carregar e interpretar o JavaScript e o CSS da página". Quando o seu código roda, o arquivo errado já está vindo pela rede.

O bloco picture pronto para colar

Este é o artefato que resolve o caso "no celular eu quero outra foto": dois arquivos, um corte de janela e o navegador escolhendo sozinho.

<picture>
  <!-- Até 640 px de janela: arquivo próprio, vertical e mais fechado no rosto. -->
  <source media="(max-width: 640px)"
          srcset="retrato-vertical-780.webp 780w,
                  retrato-vertical-1170.webp 1170w"
          sizes="100vw">
  <!-- Acima disso: o horizontal, com o espaço de texto que você reservou. -->
  <img src="retrato-1200.webp"
       srcset="retrato-960.webp 960w,
               retrato-1200.webp 1200w,
               retrato-1800.webp 1800w"
       sizes="(max-width: 1024px) 50vw, 480px"
       width="1200" height="800"
       alt="Ana Ribeiro, arquiteta, sentada à mesa de trabalho com plantas impressas">
</picture>

Em português: até 640 px de janela, use o arquivo vertical, mais fechado no rosto, nas versões de 780 e 1.170 px (que são 390 px de exibição em densidade 2 e em densidade 3); acima disso, o horizontal, entre 960, 1.200 e 1.800 px, conforme o slot do sizes.

Três regras duras, e as três são literais da documentação:

• O atributo media só existe para direção de arte. A MDN escreve, literal: "você deveria usar o atributo media somente em cenários de direção de arte". Para trocar só resolução, quem faz o trabalho é o sizes.
• O img antes do fechamento do picture é obrigatório: a MDN manda fornecer, em todos os casos, um elemento img com src e alt logo antes de fechar o picture, senão, literal, "não aparecerá imagens". O picture não desenha nada sozinho, ele só escolhe a fonte.
• O src de reserva não é enfeite. A documentação de imagens do Google diz que "alguns navegadores e rastreadores não entendem esses atributos" e recomenda "sempre especificar um URL alternativo usando o atributo src".

Repare no que esse bloco significa como decisão, e não como código: são dois arquivos, não um. A hora barata de decidir isso é antes de gerar a foto.

O retrato do topo costuma ser o elemento LCP: três decisões, e só três

A documentação de imagens do Google escreve, sem rodeio, que "as imagens geralmente são as que mais contribuem para o tamanho da página, o que pode tornar o carregamento delas lento e caro". Num site pessoal ou de serviço, a imagem que mais pesa costuma ser a sua, e ela costuma estar na primeira coisa que a pessoa vê.

Isso tem nome e métrica. O Largest Contentful Paint mede o tempo de renderização do maior elemento visível na janela, e o elemento img é um dos tipos considerados. A meta publicada é de 2,5 segundos ou menos, no percentil 75 dos carregamentos, separada entre celular e desktop. Repare no verbo: costuma. A documentação trata a imagem como candidata a elemento LCP, e quem decide de fato é o layout da sua página.

Daqui saem três decisões, e este artigo para nelas de propósito: cache, CDN e o resto ficam fora.

• Nada de loading lazy na foto da primeira dobra. A documentação de otimização de LCP traz isso num bloco marcado como aviso, e a frase, traduzida, é: "nunca faça lazy-load da sua imagem de LCP, porque isso sempre leva a atraso desnecessário de carregamento do recurso e terá impacto negativo no LCP".
• A foto precisa estar no HTML. Mesma fonte, também traduzida: "o seu recurso de LCP deve ser descobrível a partir do código-fonte HTML". Retrato de topo como background-image de CSS, ou injetado por script, é o pior caso: o navegador só descobre que ele existe depois de baixar outra coisa.
• Prioridade alta em uma imagem, não em cinco. A recomendação é usar fetchpriority alto no img que você acredita ser o elemento LCP da página, com a ressalva, no mesmo documento, de que "definir prioridade alta em mais de uma ou duas imagens torna a definição de prioridade inútil para reduzir o LCP".

O que essas três decisões compram é tempo de carregamento, e só isso. Nenhuma delas é promessa de posição em busca, e este artigo não faz essa promessa. O ganho é mais simples de descrever: quem abre a sua página vê o seu rosto antes de decidir se continua ali.

O alt de uma foto sua

A documentação de imagens do Google publica uma escada de qualidade de texto alternativo, com quatro degraus: sem texto alternativo (ruim), com excesso de palavras-chave (ruim), "filhote" (melhor) e "Cachorrinho Dálmata brincando de busca" (muito melhor). Traduza a escada para o seu retrato: alt="foto profissional" é o degrau do meio. Está preenchido, não está errado e não informa nada.

A fórmula que uso é editorial, não é spec de ninguém: quem + o que a imagem mostra + o contexto que a página não repete em texto. Dois exemplos (os nomes são exemplo, não cliente):

• Página "sobre": "Ana Ribeiro, arquiteta, sentada à mesa de trabalho com plantas impressas". O nome já está no texto da página; a cena não está.
• Página de serviço: "Ana Ribeiro em pé no canteiro de obras, de capacete branco e prancheta na mão". Aqui o alt carrega o contexto que sustenta o serviço.

A mesma documentação avisa contra o excesso: "evite o excesso de palavras-chave nos atributos alt, porque isso gera uma experiência do usuário negativa e pode fazer com que o site seja visto como spam". Empilhar "foto profissional arquiteta São Paulo foto corporativa" é o degrau ruim, e é o mais comum em site de autônomo.

Existe também o caso em que o certo é não escrever nada. Quando a mesma foto se repete no rodapé, ao lado do seu nome já escrito em texto, ela é decoração, e a MDN documenta a marcação exata no elemento img, aqui em tradução: o alt vazio "indica que esta imagem não é parte fundamental do conteúdo (é decoração ou um pixel de rastreamento), e que navegadores não visuais podem omiti-la da renderização". Alt vazio é decisão declarada; alt ausente é esquecimento.

Há um destino em que o alt vira o conteúdo mínimo garantido, porque a imagem pode não carregar: o e-mail. Esse caso está inteiro em como a foto sobrevive quando o cliente bloqueia a imagem, com a mesma regra de escrita e mais urgência.

O nome do arquivo entra na mesma conversa. A mesma documentação recomenda, sem obrigar, "combinar a extensão do nome de arquivo com o tipo de arquivo", e retrato-ana-ribeiro-arquiteta.webp descreve o que IMG_2481.jpg não descreve, nem para a busca nem para você daqui a seis meses.

Decidir na geração em vez de recortar depois

Tudo o que está acima assume um arquivo pronto. Vale voltar um passo, porque a decisão mais barata acontece antes de existir arquivo nenhum.

O gerador entrega proporções fechadas. O guia da API de imagem da OpenAI lista, entre os tamanhos populares, 1024x1024 (quadrado), 1536x1024 (horizontal) e 1024x1536 (vertical), com a restrição de que os dois lados sejam múltiplos de 16 px e o total fique entre 655.360 e 8.294.400 pixels. Escolher ali é escolher o que sobrevive depois.

A aritmética de quanto cada destino descarta a partir do arquivo horizontal já está escrita, com o valor por proporção, no artigo que gera o 3:2. Não repito a conta aqui. A consequência é o que interessa nesta página: recortar depois é escolher, num editor, qual pedaço do seu rosto sacrificar, e o recorte que o contêiner faz não é o seu.

Para um site, o par mínimo é de dois arquivos: um horizontal, para o topo e para o bloco ao lado do texto, e um mais fechado, vertical ou quadrado, para quando a caixa fica estreita no celular. A segunda foto não é uma foto nova: é a mesma sessão, mesma roupa, mesma luz, outro enquadramento. A linha que declara isso na geração é curta:

Output canvas: portrait 2:3 (1024x1536). Recompose framing for this aspect ratio.
Framing: chest-up, my eyes on the upper third line, a small margin of empty space above my hair.
Match the landscape version: same clothes, same light direction, same background.

Em português: saída vertical 2:3 em 1024x1536, com o enquadramento recomposto para essa proporção; peito para cima, olhos na linha do terço superior, uma margem pequena acima do cabelo; e mesma roupa, mesma direção de luz e mesmo fundo da versão horizontal. A primeira linha impede que a saída herde a proporção da foto que você anexou. A segunda define onde a cabeça cai no quadro, que é o Y% que você vai repetir no object-position. A terceira mantém as duas fotos parecendo da mesma pessoa, no mesmo dia. Um aviso de produto, para você não descobrir na tela: no fotoslinkedin a imagem de teste sai em 1024x1024, e as duas saídas não quadradas, 1536x1024 e 1024x1536, dependem de assinatura Pro ou Premium.

Se você também quer o avatar do rodapé, o terceiro arquivo é o quadrado, com regras próprias de escala de rosto e de fundo: estão no padrão que sobrevive à miniatura. Onde esse conjunto se encaixa, para quem trabalha por conta própria, é o kit de fotos de quem não tem departamento de marketing. E o contraste que fecha o assunto: quando você sobe a foto para uma plataforma como o Linkedin, quem manda no recorte é ela, com os tamanhos que a própria plataforma publica; aqui o dono do contêiner é você, e é por isso que existem alavancas (object-position, picture, sizes) que lá não existem.

Diagnóstico: o sintoma, a causa e a correção

Nove sintomas que aparecem quando um retrato vai parar numa página. A coluna do meio é o que está acontecendo; a da direita, a correção na ordem em que vale tentar.

Limites honestos

Nenhum tema de site publica a proporção do próprio bloco de imagem. Toda largura de exibição citada aqui é exemplo típico, e a única que vale para você é a que você mediu na sua página.

Os pesos em KB são medição minha, não regra da web: seis retratos gerados pelo próprio produto, redimensionados por largura e codificados em WebP com cwebp, mediana dos seis, em 03/08/2026. São retratos de fundo simples; foto com cenário detalhado, folhagem ou textura pesa mais. E a medição não passa de 1.024 px de largura: acima disso este artigo fala em pixels, não em KB, porque não medi.

Densidade 2 e 3 é premissa declarada, não spec de aparelho: a densidade real de quem visita a sua página não é observável antes de a página carregar.

LCP é métrica de carregamento e não é promessa de posição em busca. A própria documentação trata a imagem como candidata a elemento LCP, não como certeza: quem define o elemento é o layout, e numa página com um bloco de texto muito grande pode nem ser a foto.

A régua do object-position é derivada da regra de porcentagem da sintaxe de posição da CSS, documentada na página de background-position. Trate-a como regra que você testa no navegador, não como spec publicada para retrato.

E a contagem da busca tem regra, para você refazer: em 03/08/2026 baixei cinco páginas em português sobre tamanho e otimização de imagem para site (Shopify, Squarespace, HostGator, byb.ag e sitoweb), 13.672 palavras somadas, removi script e estilo e contei no texto visível. srcset, sizes, object-fit, picture, LCP, direção de arte, retrato e rosto dão zero nas cinco.

Resumo e próximos passos

Três decisões respondem quase tudo o que esta página discutiu. Medir: a largura de exibição do seu contêiner, multiplicada pela densidade da tela, é a largura do arquivo, e nenhum número genérico substitui essa medida. Separar dois problemas que parecem um só: nitidez se resolve com uma escada de arquivos em srcset mais sizes, enquadramento se resolve com duas fontes dentro de um picture. E não esconder o retrato da primeira dobra atrás de loading lazy nem de um background-image de CSS.

O passo anterior a todos eles continua sendo escolher a proporção na hora de gerar. Se o destino seguinte da sua foto é um documento em vez de uma página, a foto quando o destino é papel e PDF cobre o retângulo fixo do modelo de currículo, que tem regras diferentes das daqui. Se o site é só uma peça do seu material de trabalho, a lista de onde cada foto entra mostra o conjunto. E se o próximo arquivo é o horizontal do topo, a geração do 3:2 tem passo a passo próprio.