Gerador de imagens de espaço reservado

Como funciona

1. Defina as dimensões : insira a largura e a altura em pixels da sua imagem de preenchimento.
2. Personalize a aparência : escolha a cor de fundo, a cor do texto e o rótulo a ser exibido (ou deixe em branco para exibir as dimensões).
3. Use ou baixe : copie a URL da imagem para uso em HTML/CSS, ou baixe diretamente o PNG para seus mockups e designs.

Por que usar o gerador de imagens de preenchimento ?

Durante o desenvolvimento web e a criação de mockups, muitas vezes precisa-se de imagens antes que o conteúdo real esteja pronto. As imagens de preenchimento ocupam o espaço dos layouts para mostrar as proporções, testar o comportamento responsivo e comunicar a intenção de design aos clientes. Em vez de procurar fotos de banco ou criar imagens vazias manualmente, esta ferramenta gera instantaneamente imagens corretamente dimensionadas com as dimensões e cores desejadas.

Funcionalidades

• Dimensões personalizadas : qualquer largura e altura em pixels, formatos quadrado, retrato, paisagem ou banner.
• Personalização das cores : defina a cor de fundo e do texto via códigos hex ou seletores de cor.
• Texto de rótulo personalizado : exiba qualquer texto na imagem, ou mantenha por padrão o rótulo das dimensões (por ex. 400×300).
• URL instantânea : obtenha um URI de dados para colar diretamente nos atributos src para testar.
• Download PNG : baixe a imagem de preenchimento como arquivo PNG para usar em suas ferramentas de design.

Perguntas frequentes

Posso usá-la em atributos src HTML ?

Sim. A imagem gerada está disponível como URI de dados que você pode colar diretamente em um atributo <img src=""> do seu HTML. Nenhuma hospedagem ou URL externa é necessária.

Quais tamanhos são comuns para imagens de preenchimento ?

Tamanhos comuns : imagens principais (1200×630), thumbnails de artigos (400×300), avatares (100×100), imagens Open Graph (1200×628) e banners publicitários (728×90). Insira qualquer tamanho personalizado conforme suas necessidades.

Como usar imagens de preenchimento em CSS ?

Copie o URI de dados e use-o como fundo CSS : background-image: url("data:image/png;base64,…"). Isso funciona em todos os navegadores modernos e não requer nenhum arquivo externo.

Breve história dos serviços de imagens de marcador

Os serviços de imagens de marcador surgiram em 2010, quando os designers web precisavam de uma maneira rápida de preencher mockups antes que os assets finais chegassem. placehold.it, lançado por Dave Reilly em 2010, foi o primeiro serviço amplamente utilizado: cole uma URL como placehold.it/300x200 em qualquer tag <img> e obtenha um retângulo cinza. placekitten.com seguiu no mesmo ano, substituindo retângulos por gatinhos aleatórios, e dummyimage.com (Russell Heimlich, 2010) adicionou personalização de cores. Variantes caprichosas proliferaram: fillmurray.com (fotos de Bill Murray, 2013), placebeard.it (barbas, 2014), placecage.com (Nicolas Cage). Os sucessores sérios chegaram depois: Lorem Pixel (desaparecido por volta de 2017) e Lorem Picsum de David Marby (2018), que serve fotos aleatórias do Unsplash em qualquer tamanho. Por volta de 2014, o Facebook popularizou o padrão «skeleton screen»: mostrar formas cinza onde o conteúdo será carregado. Em 2019, a Wolt lançou o BlurHash, uma string de 20 bytes que decodifica para um marcador desfocado em baixa resolução da imagem real. Hoje, o ThumbHash (Evan Wallace, 2023) e a propriedade CSS nativa aspect-ratio (Chrome 88, janeiro de 2021) permitem reservar o espaço da imagem sem nenhum serviço externo.

Tamanhos padrão de imagem que vale a pena memorizar

• Open Graph (1200×630). O tamanho canônico de preview de links definido pelo protocolo Open Graph do Facebook. LinkedIn, Slack, Discord, Twitter (quando não há Twitter Card) todos recorrem a este. Proporção 1,91:1.
• Twitter Card summary_large_image (1200×675). Proporção 16:9 para previews em feed. O 1200×628 que você vê citado é o padrão antigo, substituído por 1200×675 em 2023.
• Instagram (1080×1080 quadrado, 1080×1350 retrato, 1080×1920 story). Qualquer coisa acima de 1080 de largura é sub-amostrada. A proporção de stories é 9:16.
• Miniatura do YouTube (1280×720). 16:9. O YouTube gera automaticamente estas a partir de frames de vídeo; miniaturas personalizadas enviadas devem ter menos de 2 MB.
• Tamanhos de anúncios IAB. A Interactive Advertising Bureau padronizou as dimensões de banners: 728×90 (leaderboard), 300×250 (retângulo médio, o tamanho mais comprado globalmente), 300×600 (meia página), 160×600 (skyscraper largo), 320×50 e 320×100 (mobile).
• Favicons. 16×16 e 32×32 para abas do navegador, 180×180 para ícones Apple touch, 192×192 e 512×512 para manifest.json do Android, 512×512 mínimo para prompts de instalação PWA.
• Cabeçalhos de email (600×200). A maioria dos clientes de email limita a largura renderizada a 600 px. Ir além é esmagado ou aparecem barras de rolagem no Outlook desktop.

Marcadores e Core Web Vitals

Os Core Web Vitals do Google (lançados em maio de 2020) medem a experiência do usuário e alimentam o ranking de busca. Duas das três métricas dependem diretamente de como você lida com imagens. CLS (Cumulative Layout Shift) penaliza o conteúdo que pula enquanto a página carrega. A causa mais comum: um <img> sem atributos explícitos width e height, o que dá ao navegador zero espaço para reservar até a imagem terminar de baixar. Uma pontuação acima de 0,1 falha na métrica. A correção é trivial: sempre defina width e height, mesmo em imagens responsivas, para que o navegador possa calcular a proporção. LCP (Largest Contentful Paint) mede quando o maior elemento visível carrega. Para a maioria das páginas, esse elemento é a imagem hero. Qualquer coisa acima de 2,5 segundos falha. Estratégias: servir formatos modernos (WebP, AVIF), usar loading="lazy" em imagens abaixo da dobra (Chrome 76, agosto de 2019), e usar fetchpriority="high" no hero. Os marcadores preenchem a lacuna visualmente: skeleton screens para o layout, BlurHash ou ThumbHash para uma prévia instantânea da paleta de cores da imagem real.

Guia de decisão de formatos de imagem

• PNG (1996). Sem perdas, suporta transparência, sem problemas de patentes. Ideal para logos, ícones, capturas de tela, gráficos com bordas nítidas. PNG-8 com cor indexada (256 cores) é dramaticamente menor que PNG-24 RGB e frequentemente invisível para ícones de UI.
• JPEG (1992). Com perdas, sem transparência, otimizado para fotografias. Qualidade 75-85 é o ponto ideal para a web; visualmente indistinguível da qualidade 95 com metade do tamanho. Evite JPEG para qualquer coisa com bordas nítidas (texto, logos): você obtém artefatos de ringing visíveis.
• WebP (Google, 2010). 25-35 % menor que JPEG na mesma qualidade visual, também menor que PNG para sem perdas. Suporta transparência, animação, modos com e sem perdas. Suporte de navegadores: 97 % em 2024. Escolha padrão para novos sites.
• AVIF (Alliance for Open Media, 2019). Baseado no codec de vídeo AV1. Cerca de 50 % menor que JPEG, 20 % menor que WebP. Maior custo de CPU para codificar. Suporte de navegadores: ~93 % em 2024, faltando em Safari antigos. Use atrás de um fallback <picture>.
• SVG. Vetorial. Escala infinitamente sem perda de qualidade. Um logo em SVG costuma ter 500 bytes contra 10 KB como PNG 512×512. SVG inline em HTML evita uma requisição HTTP extra completamente. Não use para fotografias.
• Data URI. data:image/png;base64,... incorpora os bytes da imagem diretamente no HTML ou CSS. Economiza uma requisição HTTP ao custo de inflar o arquivo circundante em ~33 % (overhead do base64). Vale a pena para minúsculas miniaturas placeholder, nunca para imagens hero.

Onde imagens de marcador são realmente usadas

• Wireframes e mockups. Figma, Sketch, Adobe XD, Penpot todos suportam arrastar e soltar imagens placeholder. Designers esboçam layouts antes que a direção de arte chegue, usando retângulos cinza ou o texto de dimensão como marcadores visuais.
• Skeleton screens. Twitter, Facebook, YouTube, LinkedIn todos exibem marcadores em blocos cinza enquanto o conteúdo carrega. Pesquisa de Luke Wroblewski (2013) mostra que skeleton screens fazem o tempo de carregamento percebido sentir-se até 20 % mais rápido que spinners.
• Histórias de design system. Storybook, Histoire e Ladle renderizam previews de componentes que precisam de imagens substitutas. Um conjunto consistente de placeholders torna as capturas de tela reproduzíveis entre builds de CI.
• Mockups de email. Litmus, Email on Acid, construtores de templates do Mailchimp. Clientes de email variam enormemente no suporte a imagens (Outlook desktop, Gmail web, iOS Mail), então designers testam com placeholders antes de trocar pelos assets de produção.
• Provas de impressão. Layouts de livros, páginas de revistas e designs de embalagens usam marcadores FPO («for position only») durante a composição. As dimensões vivem no layout muito antes do fotógrafo entregar.
• Tutoriais e documentação. Ao escrever «como construir um componente card», você precisa de imagens substitutas que não quebrem se a fonte mudar. Placeholders auto-hospedados sobrevivem quando serviços externos fecham (como o Lorem Pixel fez).
• Testes A/B e protótipos. Testar rapidamente layouts com três tamanhos diferentes de imagem é mais rápido com placeholders gerados do que re-renderizando assets reais.

Erros que prejudicam o desempenho da página

• Esquecer atributos width e height. A causa mais comum de pontuações CLS ruins. Mesmo com imagens responsivas dirigidas por CSS, defina os width e height intrínsecos para que o navegador reserve a proporção correta. Navegadores modernos calculam aspect-ratio: width/height automaticamente a partir desses atributos desde 2020.
• Servir placeholders 4096×4096 para exibições 200×200. Vinte vezes os bytes sem benefício visual. Combine as dimensões do placeholder com o tamanho renderizado real, ou use srcset com múltiplas variantes.
• Texto alt vazio ou ausente. Leitores de tela anunciam «imagem» sem contexto. Para placeholders puramente decorativos, use alt="" explicitamente para sinalizar «pule isto». Para imagens de conteúdo, escreva a descrição mesmo em placeholders para que o QA detecte texto faltante.
• Inlining de data URIs enormes. Uma imagem de 100 KB como base64 torna-se ~133 KB dentro do seu HTML, bloqueia o parsing e arruina o cache (HTML geralmente não é cacheado agressivamente, imagens sim). Use data URIs apenas abaixo de ~2-4 KB.
• Depender de placehold.it / lorempixel / serviços externos em produção. Eles caem. O Lorem Pixel desapareceu por volta de 2017 e quebrou milhares de sites de demo. Para tutoriais, demos e histórias, gere os placeholders você mesmo ou auto-hospede-os.
• PNG para fotografias, JPEG para logos. Uma foto como PNG é 3-5 vezes maior que a mesma imagem como JPEG. Um logo como JPEG ganha feios anéis de compressão ao redor das bordas. Escolha formato por tipo de conteúdo, não por hábito.
• Pular loading="lazy". Imagens abaixo da dobra que carregam avidamente competem por largura de banda com o hero. Adicione loading="lazy" a tudo abaixo do viewport. Nativo, sem biblioteca necessária, suportado desde Chrome 76 (agosto de 2019) e Safari 15.4 (2022).

Mais perguntas frequentes

Por que o rótulo de dimensão é tão útil em um placeholder?

Quando você tem uma dúzia de placeholders em um layout em tamanhos diferentes, o rótulo lhe diz imediatamente qual slot é qual. «400×300» em um retângulo cinza é mais informativo do que adivinhar se um card é 4:3 ou 16:9. Designers e desenvolvedores revendo um mockup podem identificar elementos mal dimensionados do outro lado da sala.

Qual a diferença entre BlurHash, ThumbHash e LQIP?

Todos os três codificam uma pequena prévia de uma imagem que decodifica para um placeholder desfocado. LQIP («low-quality image placeholder») é apenas um pequeno JPEG (~100 bytes a 2 KB). BlurHash (Wolt, 2019) codifica qualquer imagem em uma string ASCII de 20-30 caracteres que você armazena no seu banco de dados; o tempo de decodificação é em microssegundos. ThumbHash (Evan Wallace, 2023) é similar mas 30-50 % menor para a mesma qualidade, e renderiza bordas mais nítidas. Frameworks modernos (Next.js, Astro, Hugo) todos suportam BlurHash nativamente.

Devo usar SVG ou PNG para miniaturas placeholder?

SVG se o placeholder é uma forma simples (retângulo, ícone, padrão geométrico). Um SVG inline de 50 bytes vence um PNG de 2 KB toda vez. PNG se você precisa de renderização de texto precisa em pixel ou fallbacks de fonte específicos: a renderização de texto SVG varia entre navegadores e plataformas. Para placeholders dinâmicos gerados no cliente, esta ferramenta produz PNG porque a renderização de texto canvas é previsível entre navegadores.

O PNG gerado inclui EXIF ou metadados ocultos?

Não. Os PNGs gerados pelas APIs canvas HTML toBlob() ou toDataURL() contêm apenas os chunks IHDR, IDAT e IEND mais um chunk tEXt mínimo em alguns navegadores. Não há GPS, info de câmera, histórico de edição, identificador de usuário. Compare com JPEGs de câmera de celular que vazam coordenadas GPS e números de série do dispositivo.

Algo é enviado para um servidor quando gero uma imagem aqui?

Não. A imagem é desenhada localmente via a API Canvas 2D HTML5 no seu navegador. Abra a aba Network no DevTools enquanto gera: zero requisições saintes para a imagem. Seguro para mockups confidenciais, NDAs, trabalho de cliente e designs de produtos não lançados.