Generador de imágenes de marcador de posición

Cómo funciona

1. Define las dimensiones: introduce el ancho y el alto en píxeles de tu imagen de relleno.
2. Personaliza la apariencia: elige el color de fondo, el color del texto y la etiqueta a mostrar (o déjalo vacío para mostrar las dimensiones).
3. Usa o descarga: copia la URL de la imagen para uso en HTML/CSS, o descarga directamente el PNG para tus maquetas y diseños.

¿Por qué usar el generador de imágenes de relleno?

Durante el desarrollo web y la creación de maquetas, a menudo se necesitan imágenes antes de que el contenido real esté listo. Las imágenes de relleno ocupan el espacio de los diseños para mostrar proporciones, probar el comportamiento responsivo y comunicar la intención de diseño a los clientes. En lugar de buscar fotos de stock o crear imágenes vacías a mano, esta herramienta genera al instante imágenes correctamente dimensionadas con las dimensiones y colores deseados.

Funcionalidades

• Dimensiones personalizadas: cualquier ancho y alto en píxeles, formatos cuadrado, vertical, horizontal o banner.
• Personalización de colores: define el color de fondo y del texto mediante códigos hex o selectores de color.
• Texto de etiqueta personalizado: muestra cualquier texto en la imagen o deja por defecto la etiqueta de las dimensiones (p. ej. 400×300).
• URL instantánea: obtén un URI de datos para pegar directamente en los atributos src para probar.
• Descarga PNG: descarga la imagen de relleno como archivo PNG para usarla en tus herramientas de diseño.

Preguntas frecuentes

¿Puedo usarla en atributos src HTML?

Sí. La imagen generada está disponible como URI de datos que puedes pegar directamente en un atributo <img src=""> de tu HTML. No se necesita hospedaje ni URL externa.

¿Qué tamaños son habituales para las imágenes de relleno?

Tamaños habituales: imágenes principales (1200×630), miniaturas de artículos (400×300), avatares (100×100), imágenes Open Graph (1200×628) y banners publicitarios (728×90). Introduce cualquier tamaño personalizado según tus necesidades.

¿Cómo usar imágenes de relleno en CSS?

Copia el URI de datos y úsalo como fondo CSS: background-image: url("data:image/png;base64,…"). Funciona en todos los navegadores modernos y no requiere archivos externos.

Breve historia de los servicios de imágenes de marcador de posición

Los servicios de imágenes de marcador de posición surgieron en 2010 cuando los diseñadores web necesitaban una forma rápida de llenar maquetas antes de que llegaran los assets finales. placehold.it, lanzado por Dave Reilly en 2010, fue el primer servicio ampliamente usado: pega una URL como placehold.it/300x200 en cualquier etiqueta <img> y obtienes un rectángulo gris. placekitten.com siguió el mismo año, reemplazando rectángulos con gatitos aleatorios, y dummyimage.com (Russell Heimlich, 2010) añadió personalización de colores. Las variantes caprichosas proliferaron: fillmurray.com (fotos de Bill Murray, 2013), placebeard.it (barbas, 2014), placecage.com (Nicolas Cage). Los sucesores serios llegaron después: Lorem Pixel (desaparecido alrededor de 2017) y Lorem Picsum de David Marby (2018), que sirve fotos aleatorias de Unsplash a cualquier tamaño. Alrededor de 2014, Facebook popularizó el patrón «skeleton screen»: mostrar formas grises donde se cargará el contenido. Para 2019, Wolt lanzó BlurHash, una cadena de 20 bytes que se decodifica en un marcador de posición borroso de baja resolución de la imagen real. Hoy, ThumbHash (Evan Wallace, 2023) y la propiedad CSS nativa aspect-ratio (Chrome 88, enero 2021) permiten reservar el espacio de la imagen sin servicios externos en absoluto.

Tamaños de imagen estándar que vale la pena memorizar

• Open Graph (1200×630). El tamaño canónico de previsualización de enlaces definido por el protocolo Open Graph de Facebook. LinkedIn, Slack, Discord, Twitter (cuando no hay Twitter Card configurada) recurren todos a este. Relación de aspecto 1,91:1.
• Twitter Card summary_large_image (1200×675). Relación 16:9 para previsualizaciones en feed. El 1200×628 que ves citado es el estándar antiguo, reemplazado por 1200×675 en 2023.
• Instagram (1080×1080 cuadrado, 1080×1350 retrato, 1080×1920 story). Cualquier cosa por encima de 1080 de ancho se sub-muestrea. La relación de aspecto de las stories es 9:16.
• Miniatura de YouTube (1280×720). 16:9. YouTube genera automáticamente estas a partir de fotogramas de video; las miniaturas personalizadas cargadas deben pesar menos de 2 MB.
• Tamaños de anuncios IAB. La Interactive Advertising Bureau estandarizó las dimensiones de banners: 728×90 (leaderboard), 300×250 (rectángulo medio, el tamaño más comprado a nivel global), 300×600 (media página), 160×600 (rascacielos ancho), 320×50 y 320×100 (móvil).
• Favicons. 16×16 y 32×32 para pestañas del navegador, 180×180 para iconos Apple touch, 192×192 y 512×512 para manifest.json de Android, 512×512 mínimo para indicaciones de instalación de PWA.
• Cabeceras de email (600×200). La mayoría de los clientes de email limitan el ancho renderizado a 600 px. Ir más ancho se aplasta o aparecen barras de desplazamiento en Outlook desktop.

Marcadores de posición y Core Web Vitals

Los Core Web Vitals de Google (lanzados en mayo de 2020) miden la experiencia del usuario e influyen en el ranking de búsqueda. Dos de las tres métricas dependen directamente de cómo manejas las imágenes. CLS (Cumulative Layout Shift) penaliza el contenido que salta mientras la página carga. La causa más común: un <img> sin atributos explícitos width y height, lo que da al navegador cero espacio para reservar hasta que la imagen termine de descargarse. Una puntuación superior a 0,1 falla la métrica. La solución es trivial: siempre establece width y height, incluso en imágenes responsive, para que el navegador pueda calcular la relación de aspecto. LCP (Largest Contentful Paint) mide cuándo se carga el elemento visible más grande. Para la mayoría de las páginas, ese elemento es la imagen hero. Cualquier cosa que supere los 2,5 segundos falla. Estrategias: servir formatos modernos (WebP, AVIF), usar loading="lazy" en imágenes bajo la línea de flotación (Chrome 76, agosto 2019), y usar fetchpriority="high" en el hero. Los marcadores de posición llenan el vacío visualmente: skeleton screens para el layout, BlurHash o ThumbHash para una vista previa instantánea de la paleta de colores de la imagen real.

Guía de decisión de formatos de imagen

• PNG (1996). Sin pérdida, soporta transparencia, sin problemas de patentes. Ideal para logos, iconos, capturas de pantalla, gráficos con bordes nítidos. PNG-8 de color indexado (256 colores) es dramáticamente más pequeño que PNG-24 RGB y a menudo invisible para iconos de UI.
• JPEG (1992). Con pérdida, sin transparencia, optimizado para fotografías. Calidad 75-85 es el punto óptimo para la web; visualmente indistinguible de calidad 95 a la mitad del tamaño. Evita JPEG para cualquier cosa con bordes nítidos (texto, logos): obtienes artefactos de ringing visibles.
• WebP (Google, 2010). 25-35 % más pequeño que JPEG con la misma calidad visual, también más pequeño que PNG para sin pérdida. Soporta transparencia, animación, modos con y sin pérdida. Soporte de navegadores: 97 % a 2024. Elección por defecto para sitios nuevos.
• AVIF (Alliance for Open Media, 2019). Basado en el códec de video AV1. Aproximadamente 50 % más pequeño que JPEG, 20 % más pequeño que WebP. Mayor coste de CPU para codificar. Soporte de navegadores: ~93 % a 2024, faltando en Safari antiguos. Usa detrás de un fallback <picture>.
• SVG. Vectorial. Escala infinitamente sin pérdida de calidad. Un logo en SVG suele ser de 500 bytes frente a 10 KB en PNG 512×512. SVG inline en HTML evita por completo una petición HTTP extra. No usar para fotografías.
• Data URI. data:image/png;base64,... incrusta los bytes de la imagen directamente en HTML o CSS. Ahorra una petición HTTP a costa de inflar el archivo circundante un ~33 % (sobrecarga de base64). Vale la pena para diminutas miniaturas placeholder, nunca para imágenes hero.

Dónde se usan realmente las imágenes de marcador de posición

• Wireframes y maquetas. Figma, Sketch, Adobe XD, Penpot todos soportan arrastrar y soltar imágenes placeholder. Los diseñadores bosquejan layouts antes de que llegue la dirección artística, usando rectángulos grises o el texto de dimensión como marcadores visuales.
• Skeleton screens. Twitter, Facebook, YouTube, LinkedIn todos muestran marcadores de bloques grises mientras se carga el contenido. La investigación de Luke Wroblewski (2013) muestra que las skeleton screens hacen sentir el tiempo de carga percibido hasta 20 % más rápido que los spinners.
• Historias de design system. Storybook, Histoire y Ladle renderizan vistas previas de componentes que necesitan imágenes de reemplazo. Un conjunto coherente de placeholders hace las capturas de pantalla reproducibles entre builds de CI.
• Maquetas de email. Litmus, Email on Acid, los constructores de plantillas de Mailchimp. Los clientes de email varían enormemente en soporte de imágenes (Outlook desktop, Gmail web, iOS Mail), así que los diseñadores prueban con placeholders antes de cambiar a assets de producción.
• Pruebas de impresión. Layouts de libros, páginas de revistas y diseños de embalaje usan marcadores FPO («for position only») durante la composición. Las dimensiones viven en el layout mucho antes de que el fotógrafo entregue.
• Tutoriales y documentación. Cuando escribes «cómo construir un componente card», necesitas imágenes de reemplazo que no se rompan si la fuente cambia. Los placeholders auto-hospedados sobreviven cuando los servicios externos cierran (como hizo Lorem Pixel).
• Tests A/B y prototipos. Probar rápidamente layouts con tres tamaños de imagen diferentes es más rápido con placeholders generados que re-renderizando los assets reales.

Errores que dañan el rendimiento de la página

• Olvidar los atributos width y height. La causa más común de malas puntuaciones CLS. Incluso con imágenes responsive controladas por CSS, establece los width y height intrínsecos para que el navegador reserve la relación de aspecto correcta. Los navegadores modernos calculan aspect-ratio: width/height automáticamente desde estos atributos desde 2020.
• Servir placeholders 4096×4096 para visualizaciones 200×200. Veinte veces los bytes sin beneficio visual. Empareja las dimensiones del placeholder con el tamaño renderizado real, o usa srcset con múltiples variantes.
• Texto alt vacío o ausente. Los lectores de pantalla anuncian «imagen» sin contexto. Para placeholders puramente decorativos, usa alt="" explícitamente para señalar «omite esto». Para imágenes de contenido, escribe la descripción incluso en placeholders para que QA detecte texto faltante.
• Inlining de data URIs enormes. Una imagen de 100 KB como base64 se convierte en ~133 KB dentro de tu HTML, bloquea el parsing y arruina el caché (el HTML no suele cachearse agresivamente, las imágenes sí). Usa data URIs solo bajo ~2-4 KB.
• Depender de placehold.it / lorempixel / servicios externos en producción. Se caen. Lorem Pixel desapareció alrededor de 2017 y rompió miles de sitios de demo. Para tutoriales, demos e historias, genera los placeholders tú mismo o auto-hospedalos.
• PNG para fotografías, JPEG para logos. Una foto como PNG es 3-5 veces más grande que la misma imagen como JPEG. Un logo como JPEG obtiene feos anillos de compresión alrededor de los bordes. Elige formato por tipo de contenido, no por hábito.
• Saltar loading="lazy". Las imágenes bajo la línea de flotación que cargan ávidamente compiten por ancho de banda con el hero. Añade loading="lazy" a todo lo que esté bajo el viewport. Nativo, sin biblioteca necesaria, soportado desde Chrome 76 (agosto 2019) y Safari 15.4 (2022).

Más preguntas frecuentes

¿Por qué la etiqueta de dimensión es tan útil en un placeholder?

Cuando tienes una docena de placeholders en un layout con diferentes tamaños, la etiqueta te dice inmediatamente qué slot es cuál. «400×300» en un rectángulo gris es más informativo que adivinar si una card es 4:3 o 16:9. Diseñadores y desarrolladores que revisan una maqueta pueden detectar elementos mal dimensionados desde el otro lado de la habitación.

¿Cuál es la diferencia entre BlurHash, ThumbHash y LQIP?

Los tres codifican una diminuta vista previa de una imagen que se decodifica en un placeholder borroso. LQIP («low-quality image placeholder») es solo un JPEG pequeño (~100 bytes a 2 KB). BlurHash (Wolt, 2019) codifica cualquier imagen en una cadena ASCII de 20-30 caracteres que almacenas en tu base de datos; el tiempo de decodificación es de microsegundos. ThumbHash (Evan Wallace, 2023) es similar pero 30-50 % más pequeño para la misma calidad, y renderiza bordes más nítidos. Los frameworks modernos (Next.js, Astro, Hugo) soportan BlurHash de fábrica.

¿Debería usar SVG o PNG para miniaturas placeholder?

SVG si el placeholder es una forma simple (rectángulo, icono, patrón geométrico). Un SVG inline de 50 bytes vence a un PNG de 2 KB siempre. PNG si necesitas renderizado de texto preciso al píxel o fallbacks de fuente específicos: el renderizado de texto SVG varía entre navegadores y plataformas. Para placeholders dinámicos generados en el cliente, esta herramienta produce PNG porque el renderizado de texto canvas es predecible entre navegadores.

¿El PNG generado incluye EXIF o metadatos ocultos?

No. Los PNG generados por las APIs canvas HTML toBlob() o toDataURL() contienen solo los chunks IHDR, IDAT e IEND más un chunk tEXt mínimo en algunos navegadores. No hay GPS, ni info de cámara, ni historial de edición, ni identificador de usuario. Compara con JPEGs de cámara de teléfono que filtran coordenadas GPS y números de serie del dispositivo.

¿Se envía algo a un servidor cuando genero una imagen aquí?

No. La imagen se dibuja localmente vía la API Canvas 2D HTML5 en tu navegador. Abre la pestaña Network en DevTools mientras generas: cero peticiones salientes para la imagen. Seguro para maquetas confidenciales, NDA, trabajo de cliente y diseños de productos no lanzados.