O que o Linkedin faz com a sua foto depois que você aperta salvar

O que acontece entre o clique em salvar e o pixel na tela

Você exportou a foto grande, olhou no computador, aprovou e subiu. A página recarrega e o rosto na tela não é bem o que você mandou: a pele parece mole, a gola vermelha ganhou uma borda suja, e na lista de resultados de busca a mesma foto parece pior ainda. Se você chegou aqui procurando por que a foto do Linkedin fica borrada depois do upload, a resposta curta é que quase nada disso é defeito do arquivo que você enviou. Não é impressão sua: o que aparece na tela é outro arquivo.

A fronteira deste texto é o botão salvar. Tudo que espremeu a foto antes dele, o envio por aplicativo de mensagem, a captura de tela, a cópia que voltou da nuvem, está em tudo que espremeu o arquivo antes de ele chegar ao formulário. Aqui começa o outro lado.

A referência de campos da foto de perfil publicada pela própria empresa descreve o modelo em que isso acontece. É documentação de API, versão 2, com carimbo de 2023-05-08: ela prova o modelo, não o comportamento do produto de consumidor hoje. Somando o que ela descreve com o que eu medi nos arquivos servidos em 09/08/2026, o percurso tem cinco etapas.

1. Recebe o arquivo. A Ajuda publica o que é aceito no envio: PNG ou JPG, até 8 MB, entre 400 por 400 e 7.680 por 4.320 px, sem GIF (consultada em 09/08/2026). Essa spec tem dono no acervo, na página que responde o que mandar, e não o que voltou, e aparece aqui uma vez só.
2. Guarda um original que só você vê. A referência descreve o campo originalImage com a observação de que ele aparece apenas na visão do próprio dono.
3. Deriva artefatos de tamanho fixo. Na resposta de exemplo, o identificador da mídia carrega o nome da derivação, profile-displayphoto-shrink_100_100, e um storageSize de 100 por 100.
4. Recodifica em JPEG. A mesma resposta declara mediaType image/jpeg. E o que chega do outro lado vem sem rótulo nenhum: nos 26 arquivos que baixei, nenhum trazia orientação, perfil de cor, XMP ou caixa de proveniência.
5. Entrega por endereço assinado, com prazo. O modelo prevê um campo de expiração do identificador, e o cabeçalho dos arquivos que medi declarava validade de 24 horas.

Guarde a etapa 3, que é a que ninguém escreve e a que explica o sintoma que trouxe você até aqui. A foto que aparece no seu perfil, a bolinha do feed e a imagem da lista de busca não são a mesma foto reduzida pelo navegador na hora. São arquivos diferentes, gerados antes, cada um com o próprio endereço. Por isso uma pode estar boa e a outra não.

Sintoma por sintoma: em que etapa o seu problema nasce

Antes da evidência, o diagnóstico. A tabela abaixo é o resumo executável deste artigo: cada linha pega um sintoma que aparece nas buscas, diz em qual das cinco etapas ele nasce, o que resolve e o que não adianta fazer. A última coluna existe porque a reação intuitiva costuma ser a errada, e custa tempo e uma foto pior.

O que eu medi em 26 arquivos servidos pela rede

Método primeiro, porque medição sem método é adjetivo. Em 09/08/2026, sem conta, sem cookie e sem cabeçalho especial, baixei o HTML de duas páginas públicas de perfil de figuras públicas. Extraí toda URL de mídia que aparecia ali, agrupei por par de identificador do ativo e classe de artefato e fiquei com 26 pares distintos. Baixei os 26 e li o binário: marcadores do arquivo, tabelas de quantização, fatores de amostragem e presença de orientação, perfil de cor, XMP e caixa de proveniência. Nenhum nome, identificador ou imagem de terceiro é publicado aqui, e os arquivos foram apagados depois da leitura.

A parte que costuma ficar de fora é como se lê qualidade dentro de um JPEG. Não existe campo nenhum escrito qualidade 90 no arquivo: existe a tabela de quantização, que é a tabela padrão escalada por uma fórmula, e a fórmula está no código de referência do libjpeg-turbo:

jpeg_quality_scaling(q):   se q >= 50,  fator = 200 - q * 2

tabela padrão (luminância), primeira linha:   16   11   10   16   24   40   51   61
q = 90  ->  fator = 20
valor final = (valor * fator + 50) / 100, truncado, mínimo 1
primeira linha resultante:                     3    2    2    3    5    8   10   12

Em português: o codificador pega uma tabela fixa, multiplica cada número por um fator que vem da qualidade escolhida e trunca. Qualidade alta gera divisores pequenos, e divisor pequeno joga fora menos detalhe. Comparei a tabela de cada arquivo baixado, coeficiente a coeficiente, com essa tabela escalada para cada valor de 1 a 100. Nos 26 arquivos o casamento foi exato e único: só o 90 reproduz o que está gravado ali. As tabelas de partida são as da recomendação ITU-T T.81, que é onde elas vivem desde 1992.

As classes de artefato que apareceram, todas na mesma página e sem sessão nenhuma:

O nome da classe não é decoração. Ele descreve a derivação inteira, e é a informação que some de toda a conversa em português sobre foto de perfil borrada:

profile-displayphoto-shrink_400_400
        |            |        |   |
        |            |        |   +--- altura máxima da derivação, em px
        |            |        +------- largura máxima, em px
        |            +---------------- regra: shrink (encaixa) ou scale
        +----------------------------- do que é a foto: displayphoto ou displaybackgroundimage

Quatro coisas saltam dessa leitura.

1. A receita é uma só. Vinte e seis arquivos, dois perfis diferentes, três famílias de artefato, e a mesma tabela de quantização em todos. Não existe compressão que fica mais dura quando a sua foto é ruim. Existe uma configuração fixa, e ela é alta.
2. A derivação encaixa, não estica. Um dos arquivos pedidos como shrink_400_400 voltou com 333 por 333 px. É observação única, n igual a 1, e precisa ser lida assim: naquele caso a derivação encaixou o original dentro do teto em vez de esticá-lo.
3. O endereço é assinado por derivação. Troquei a classe dentro do endereço mantendo a assinatura e 26 de 26 responderam 403. Não existe pedir a versão maior. Quem decide qual derivação chega a quem olha é a plataforma, e isso é um limite a entender, não um método de coleta a repetir.
4. Nenhum metadado sobrevive. Nem orientação, nem perfil de cor, nem proveniência. Isso tem consequência prática e ganha seção própria mais abaixo.

O menor número da tabela já tinha aparecido no acervo, e o crédito é do irmão: a medição que já tinha olhado a superfície pública dessa foto registrou, em 06/08/2026, uma versão de 200 por 200 px com 6.598 bytes e nenhum metadado. O que é novo aqui é a amostra de 26 arquivos, a leitura da tabela de quantização e o comportamento do endereço quando se troca a classe.

Por que a foto do Linkedin fica borrada: encolher não é recodificar

A página em inglês que chega mais perto disso na busca já enuncia a tese, e o crédito é dela: ela escreve que a rede escala e recomprime a foto de perfil no momento do envio (tradução minha), e recomenda decidir o recorte antes. Está certa no mecanismo. O que falta ali, e falta em todas as outras, é a medida: agressiva é adjetivo, e a leitura das tabelas diz o contrário, qualidade 90 numa escala que vai até 100.

Se a compressão é alta, por que a foto fica mole? Porque encolher e recodificar são duas etapas diferentes, e a busca inteira trata as duas como uma coisa só. Separei as duas com uma segunda medição.

Simulei as duas etapas finais com exatamente os parâmetros lidos nos arquivos servidos (qualidade 90 na escala do libjpeg, um valor de cor por bloco de 2 por 2 pixels, varredura progressiva) e comparei por PSNR contra o mesmo quadro só redimensionado, sem passar por JPEG. Assim o encolhimento sai da conta e sobra o custo da codificação, isolado. A amostra são seis retratos de 1.024 por 1.024 px, todos imagens geradas por IA, personas sintéticas do acervo deste blog, mais um gráfico de teste sintético de 1.200 por 1.200 px com linhas pretas de 1 px, uma faixa de vermelho saturado sobre cinza, texto de 14 e 28 px e um gradiente de pele.

Leitura da tabela. No retrato, a codificação inteira custa entre 39 e 43 dB, com erro máximo de 25 a 42 níveis num pixel isolado. Isso é pouco. E a mediana de bytes da simulação, 24.240 no arquivo de 400 px, fica na mesma ordem de grandeza da mediana medida nos arquivos servidos, 28.793 bytes, o que é justamente o que autoriza usar a simulação para explicar o arquivo real.

O que apaga o rosto é a outra etapa, e ela não tem sutileza nenhuma. De um arquivo de 1.024 px de lado para a derivação de 400 px sobram 15,26% dos pixels; para a de 200 px, 3,81%. Se a foto saiu de um celular de 12 MP e você recortou em quadrado, algo perto de 3.024 px de lado, sobram 1,75% e 0,44%. As contas são 400²/1024², 200²/1024², 400²/3024² e 200²/3024², e dá para refazer no papel em trinta segundos. Nenhum codificador do mundo recupera informação que não foi levada para a grade menor.

A metade que a compressão realmente estraga tem endereço: cor saturada. O codificador guarda o brilho pixel a pixel e a cor em resolução menor, um valor de cor para cada bloco de 2 por 2 pixels. É o padrão declarado no próprio código de referência do libjpeg, num comentário que diz, em inglês, que a redução de croma de 2 por 2 é o comportamento padrão. No retrato isso quase não aparece. É o que as duas últimas linhas da tabela acima mostram: a faixa de vermelho sobre cinza despenca para 25,23 dB no arquivo de 200 px, com picos de erro de 76 níveis no canal vermelho, enquanto as linhas pretas da mesma imagem seguem em 42,57 dB.

Tradução para o guarda-roupa: gola vermelha, logo colorido, crachá e texto colorido perto do rosto é que viram papa. A pele não. Se a sua reclamação é que a foto ficou suja, e não mole, olhe para a cor da peça antes de olhar para a resolução. E se a cor mudou de tela para tela, em vez de sujar na borda, o problema é outro e tem casa própria: por que a mesma cor não sobrevive de uma tela para a outra.

Por que subir em PNG não protege a sua foto

A Ajuda aceita PNG no envio: o tipo de arquivo precisa ser PNG ou JPG, e GIF fica de fora (página consultada em 09/08/2026). Daí sai a receita mais repetida da busca em inglês, a de salvar em PNG para preservar qualidade. Nos 26 arquivos que medi, o que a rede entrega é image/jpeg em 26 de 26. PNG protege o caminho até o formulário. Não protege o que vem depois dele.

Vale separar as duas metades, porque as duas são verdade ao mesmo tempo. PNG é o formato certo para o arquivo não perder nada enquanto passa pela sua mão, e esse percurso tem dono no acervo: onde o arquivo perde pixel antes de você clicar em enviar. Depois do salvar, o formato servido não é decisão sua.

A mesma página que recomenda PNG responde à pergunta do borrado com dois motivos que divergem do que a Ajuda publica: imagem menor que 300 por 300 px, e arquivo acima de 8 MB que a plataforma comprimiria (guia de especificação em inglês). A página oficial em português escreve outra coisa: a faixa aceita começa em 400 por 400 px, e os 8 MB aparecem como teto do arquivo numa página que existe justamente para explicar por que a foto não carrega, ou seja, como condição de envio e não como gatilho de compressão. Vale abrir os dois e conferir.

Circula também a receita simétrica, a de que enviar uma imagem pequena demais faz a rede ampliar o arquivo e criar pixelização. Ela aparece em guias comerciais de tamanho, e nenhuma das cinco páginas que li para escrever isto mostra uma medição ao lado da afirmação: por isso ela entra aqui como coisa que se repete, não como fonte. O que dá para publicar é o que eu medi: o único dos meus 26 arquivos que fugiu do teto da classe veio menor, com 333 px de lado num artefato de 400, e não maior. É observação única, com n igual a 1, e não desmente nada sozinha. É só a única evidência medida em cima da mesa, e ela aponta para o lado contrário.

Girada, sem cor e sem metadado: o que sobra do arquivo

Nos 26 arquivos: zero marcador de orientação, zero perfil de cor, zero XMP, zero caixa de proveniência. Um único marcador de aplicativo e um cabeçalho de 244 a 623 bytes antes de começarem os dados de imagem. Isso tem três consequências práticas, e as três aparecem como reclamação nas buscas.

A foto que subiu girada

O navegador sabe girar a imagem sozinho quando o arquivo traz o marcador de orientação. A referência de CSS para orientação de imagem diz que o valor inicial é from-image e que a informação de orientação contida na imagem é usada para girá-la apropriadamente. No arquivo servido não existe esse marcador para o navegador seguir. A orientação que aparece é a que ficou gravada nos pixels.

Não estou afirmando o que o servidor faz no momento da recodificação, porque isso eu não medi: estou dizendo o que chega. A correção prática é reexportar a foto já girada, com a rotação aplicada de verdade, antes de subir. Se ela já está no ar torta, a própria Ajuda lista girar entre os controles do editor de foto de perfil.

A cor sem rótulo

Sem perfil de cor embutido, a web lê o arquivo como sRGB e pronto. O artigo do acervo que cuida disso registrou, em 09/08/2026, que a página oficial não publica uma linha sobre perfil de cor, espaço de cor ou ICC; a minha leitura mostra o outro lado da mesma moeda, o arquivo servido chegando sem rótulo nenhum em 26 de 26. Os dois fatos combinam, e a explicação de espaço de cor fica lá, no artigo que trata do rótulo de cor que some do arquivo.

O recorte e o filtro que você fez no editor

O que você faz dentro do editor da rede também não vira um arquivo seu. A referência descreve um campo de informação sobre as operações de filtro aplicadas à foto de perfil, declarado como opcional: recorte e filtro ficam guardados como informação à parte, ao lado da imagem, e não como um novo original que você controla. Isso não quer dizer que dê para desfazer, e a documentação não promete isso. Quer dizer que a decisão boa é a de origem. O que os controles do editor mexem de verdade tem uma página inteira dedicada no acervo.

A foto antiga que insiste, e por que limpar o cache quase nunca resolve

O conselho que circula é limpar o cache do navegador. Ele quase nunca resolve, e a razão está no endereço do arquivo. O identificador da mídia carrega um carimbo de tempo: nos arquivos que li, os carimbos embutidos apontavam para datas de criação diferentes entre si, separadas por anos. Foto nova ganha endereço novo. Se alguém ainda vê a antiga, não é porque o navegador está segurando o endereço atual, é porque uma cópia velha continua viva em algum lugar.

Os arquivos vinham com um cabeçalho de cache público e validade de 86.400 segundos. A referência de HTTP para esse cabeçalho traduz as duas metades: a validade indica que a resposta permanece fresca até aquele número de segundos depois de ter sido gerada, e o modo público indica que ela pode ficar guardada em um cache compartilhado, ou seja, não só no seu navegador. E 86.400 segundos são exatamente 24 horas.

Três lugares onde a cópia velha sobrevive, e o que dá para fazer em cada um:

• A aba ou o aplicativo que já estava aberto quando você trocou. Fechar e abrir de novo resolve. É o único caso em que recarregar tem algum efeito.
• Quem já tinha o endereço antigo copiado. Uma mensagem, um cartão de contato, um sistema interno que salvou a imagem. Aí não existe botão nenhum: aquela cópia virou um arquivo que outra pessoa guardou.
• Índices e cópias fora da plataforma. Resultados de busca externos e sites que espelham perfil atualizam no ritmo deles. A foto de perfil é uma superfície pública, e o mapa dela está no levantamento do que fazer quando a sua imagem circula fora do seu controle.

O que não dá para forçar: não existe botão de expirar as cópias antigas, porque a validade declarada é do arquivo, não da sua conta. Por isso o protocolo da próxima seção insiste em trocar uma vez e esperar. Trocar três vezes em dez minutos porque a bolinha do feed não mudou só multiplica endereços.

Decisão sua, decisão da plataforma

Quase toda frustração com foto de perfil vem de tentar controlar o lado que não é seu. A separação abaixo é o fecho honesto do assunto, e ela não é opinião: cada linha da coluna do meio sai ou da referência de campos ou da medição dos 26 arquivos.

Vale registrar até onde vai o compromisso publicado. As diretrizes de foto de perfil da própria rede dizem que a sua foto de perfil deve ser semelhante a você. Semelhança é o que está prometido. Nitidez, cor e formato do arquivo servido não estão nessa lista, e cobrar isso da plataforma é cobrar o que ela nunca ofereceu.

Protocolo de troca de foto em 5 passos, e a verificação em 3

Junte tudo e sobra um procedimento curto. Ele não promete nitidez: promete que você não vai perder pixel por engano nem concluir coisa errada sobre o resultado. Os dois erros mais caros que ele evita são enviar um arquivo já espremido e trocar de novo antes de a troca aparecer.

1. Recorte o quadrado antes de subir. A derivação encaixa o que você mandou dentro do teto dela, então recorte deixado para depois vira pixel jogado fora duas vezes. A régua de quanto o rosto precisa ocupar num quadrado está na régua que diz o que sobrevive quando a foto encolhe.
2. Gire e reexporte antes, nunca depois. Aplique a rotação nos pixels e salve de novo. O arquivo entregue pela rede não leva marcador de orientação junto, então o que estiver torto no pixel fica torto na tela.
3. Teste a legibilidade no pequeno. Reduza a sua foto para 200 px de lado no computador e olhe de longe. É o mesmo lado do menor artefato que apareceu na medição. O que sumir ali vai sumir para quem te encontra numa lista de resultados.
4. Troque uma vez. Uma troca, um arquivo. Cada nova tentativa gera mais um endereço, e nenhuma delas apaga as cópias que já saíram.
5. Espere antes de julgar. O cabeçalho dos arquivos declarava 24 horas de frescor. Julgar em cinco minutos, na mesma aba em que você fez a troca, é julgar a cópia velha.

Depois de trocar, a verificação leva menos de dois minutos e não pede ferramenta nenhuma:

1. Abra o seu próprio perfil em janela anônima. Sem sessão, você enxerga a superfície pública, que é aproximadamente o que quem não é sua conexão recebe.
2. Compare a versão pequena com a da página. Se a pequena está ruim e a da página está boa, são dois arquivos diferentes e o seu problema é de composição, não do arquivo que você enviou.
3. Decida se o que mudou foi o arquivo ou a exibição. Mesma foto com aparências diferentes em superfícies diferentes é exibição, e se resolve compondo para o menor quadro. Mesma foto ruim em todas as superfícies é arquivo enviado, e se resolve reenviando um quadrado maior e nítido.

O que esta medição não prova

Todo número deste artigo tem um contorno, e é mais barato escrever o contorno do que deixar você descobrir sozinho:

• Dois perfis, um dia, uma borda da rede de entrega, em visita anônima e sem sessão. Não é censo, não é a foto que você vê logado no seu perfil, não é a que o aplicativo do celular entrega e não é promessa de que amanhã seja igual.
• A qualidade lida é a configuração da última codificação, gravada na tabela do próprio arquivo. Ela não diz quantas vezes aquela imagem já tinha sido recodificada antes.
• PSNR é métrica de sinal, em decibel. Não é medida de percepção e não vira porcentagem de perda.
• As personas usadas na simulação são imagens geradas por IA, não fotografias de câmera, e o gráfico de teste é sintético de propósito, para achar onde a cor dói.
• A simulação usa libjpeg com os parâmetros lidos no arquivo servido, e não o codificador da plataforma, que não é público.
• A referência de campos é documentação de API, versão 2, com carimbo de 2023-05-08. Ela sustenta o modelo (um original guardado, derivações de tamanho fixo, JPEG, endereço com prazo), não o que o produto de consumidor faz hoje.
• O arquivo de 333 por 333 px é uma observação única. Vale como indício contra a tese de que a derivação amplia, não como prova de regra.

Resumo e próximos passos

Cinco frases para levar. A rede não guarda a sua foto: guarda um original que só o dono vê e serve derivações de tamanho fixo, em JPEG. A compressão dessas derivações é alta e igual em todas, qualidade 90 nos 26 arquivos medidos em 09/08/2026. O que apaga o rosto é o encolhimento, e a conta é 15,26% dos pixels sobrando na derivação de 400 px e 3,81% na de 200. O que a compressão realmente suja é borda de cor saturada, não pele. E metadado nenhum atravessa, o que explica de uma vez a foto girada, a cor sem rótulo e a proveniência ausente.

O próximo passo é o protocolo, na ordem: recorte quadrado, rotação aplicada nos pixels, teste em 200 px, uma troca só, 24 horas de paciência antes de julgar. Se a sua dúvida for anterior a tudo isso, sobre como a foto precisa ser antes de virar arquivo, o mapa está no guia que decide como a foto tem que ser antes de virar arquivo. E se ela for posterior, sobre a foto que continua circulando depois de trocada, o caminho é o artigo de superfície pública já linkado acima.