{"id":29931,"date":"2026-10-08T16:44:40","date_gmt":"2026-10-08T14:44:40","guid":{"rendered":"https:\/\/ingenio.la\/blog\/?p=29931"},"modified":"2026-10-06T17:19:03","modified_gmt":"2026-10-06T15:19:03","slug":"formatos-de-fotos","status":"publish","type":"post","link":"https:\/\/ingenio.la\/blog\/formatos-de-fotos\/","title":{"rendered":"Formatos de fotos: cu\u00e1l usar en cada sitio y qu\u00e9 pasa cuando te equivocas"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Subir una foto de cuatro megas a un sitio web parece inofensivo hasta que alguien mide cu\u00e1nto tarda en cargar la p\u00e1gina en un tel\u00e9fono con datos m\u00f3viles. Ah\u00ed es donde los formatos de fotos<\/strong> dejan de ser un detalle t\u00e9cnico y pasan a ser la causa.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

La parte confusa es que las gu\u00edas del tema terminan todas en la misma tabla comparativa, y despu\u00e9s nadie explica lo que pasa de verdad en un sitio: que el formato que subes casi nunca es el que recibe el visitante.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Vale entonces separar tres cosas: en qu\u00e9 se diferencian los formatos, cu\u00e1l usar seg\u00fan d\u00f3nde va la imagen, y qu\u00e9 hace el servidor con ella sin pedir permiso.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

En qu\u00e9 se diferencian los formatos de fotos, m\u00e1s all\u00e1 de la extensi\u00f3n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Solo hay tres propiedades que importan para decidir, y las dem\u00e1s se derivan de ellas. La primera es si la compresi\u00f3n pierde informaci\u00f3n o no. Un formato con p\u00e9rdida descarta detalle que el ojo apenas registra para ahorrar peso, y cada vez que se vuelve a guardar descarta un poco m\u00e1s. Uno sin p\u00e9rdida conserva todo y pesa m\u00e1s.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

La segunda es si admite transparencia. Un logotipo sobre un fondo de color necesita que el \u00e1rea alrededor sea transparente; una fotograf\u00eda no lo necesita nunca. Esa \u00fanica pregunta ya descarta la mitad de las opciones en cada caso.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

La tercera es la eficiencia a igual calidad, que es donde la generaci\u00f3n nueva de formatos gana. WebP, que Google public\u00f3 en 2010 como sucesor de los dos cl\u00e1sicos, consigue entre un 25% y un 35% menos de peso con calidad equivalente, y adem\u00e1s admite transparencia y animaci\u00f3n. AVIF, desarrollado por la Alliance for Open Media, aprieta todav\u00eda m\u00e1s.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Hay una cuarta propiedad que no es de compresi\u00f3n y conviene nombrar: si la imagen est\u00e1 hecha de p\u00edxeles o de instrucciones. Los formatos vectoriales escalan sin perder nitidez a cualquier tama\u00f1o, pero no sirven para fotograf\u00edas; son para logotipos, iconos y gr\u00e1ficos. Una foto siempre va en un formato de p\u00edxeles.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

Cu\u00e1l usar seg\u00fan d\u00f3nde va la imagen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La decisi\u00f3n se resuelve con dos preguntas: qu\u00e9 contiene la imagen y d\u00f3nde se va a ver.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t
Qu\u00e9 es la imagen<\/th>Formato recomendado<\/th><\/tr><\/thead>
Fotograf\u00eda con muchos colores y degradados<\/td>JPG, o WebP si el sitio lo admite<\/td><\/tr>
Logotipo, icono o captura con texto n\u00edtido<\/td>PNG<\/td><\/tr>
Cualquier imagen de una web moderna<\/td>WebP<\/td><\/tr>
Imagen grande donde el peso es cr\u00edtico<\/td>AVIF<\/td><\/tr>
Foto que se va a editar varias veces<\/td>Un formato sin p\u00e9rdida mientras se trabaja<\/td><\/tr><\/tbody><\/table>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

En redes sociales la tabla importa menos de lo que parece, porque cada plataforma recomprime lo que se sube con sus propios par\u00e1metros. Lo que s\u00ed controla quien publica es la calidad de partida y las dimensiones: subir una imagen m\u00e1s peque\u00f1a que el tama\u00f1o en que se va a mostrar garantiza que se vea mal, y ninguna elecci\u00f3n de formato arregla eso.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

El error m\u00e1s com\u00fan no es elegir mal el formato, sino subir el archivo que sali\u00f3 de la c\u00e1mara. Una foto de doce megap\u00edxeles mostrada en un bloque de ochocientos p\u00edxeles de ancho est\u00e1 entregando quince veces m\u00e1s informaci\u00f3n de la que se va a ver, y el navegador tiene que descargarla completa antes de reducirla. Ajustar eso es parte del trabajo de creaci\u00f3n de contenido<\/a> aunque no se parezca en nada a escribir.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

El formato que subes no es el que recibe el visitante<\/h2>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Esta es la parte que las comparativas omiten y la que m\u00e1s confunde a quien administra un sitio. Casi cualquier gestor de contenidos con un plugin de optimizaci\u00f3n instalado hace dos cosas en silencio: genera varios tama\u00f1os de cada imagen y crea una copia en un formato m\u00e1s eficiente.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

A partir de ah\u00ed, lo que el navegador descarga lo decide el servidor seg\u00fan lo que ese navegador declare aceptar. Sube un JPG y es muy probable que tu visitante est\u00e9 recibiendo un WebP que t\u00fa nunca creaste. Esto funciona bien y resuelve el problema sin intervenci\u00f3n, con un efecto lateral molesto: la copia servida suele vivir en una carpeta distinta de la original.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Ese detalle cuesta horas cuando algo falla. Buscar una imagen por la ruta con la que se subi\u00f3 no la encuentra, porque la que se est\u00e1 sirviendo est\u00e1 en otra parte. Es el tipo de cosa que hace concluir que una imagen no existe cuando lo \u00fanico que pasa es que se estaba mirando el sitio equivocado. Conviene comprobarlo abriendo la p\u00e1gina y mirando qu\u00e9 archivo pidi\u00f3 el navegador, no la biblioteca de medios.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

La conclusi\u00f3n operativa es contraintuitiva: si el servidor ya convierte, no vale la pena convertir a mano antes de subir. Lo que s\u00ed vale es subir el original con buena calidad y en dimensiones razonables, porque la conversi\u00f3n autom\u00e1tica puede reducir peso pero no puede inventar detalle que no estaba. Es parte del mismo trabajo que cubre cualquier plan de optimizaci\u00f3n web<\/a>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t

Qu\u00e9 hacer con las fotos que ya est\u00e1n subidas<\/h2>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Casi ning\u00fan sitio empieza de cero: lo normal es heredar una biblioteca de medios con a\u00f1os de archivos subidos sin criterio. Revisarla entera rara vez compensa, y por eso conviene empezar por donde el peso duele.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

El orden que funciona es por visibilidad. Primero las im\u00e1genes de la portada y de las p\u00e1ginas que reciben m\u00e1s visitas, porque ah\u00ed cada kilobyte se paga en cada sesi\u00f3n. Despu\u00e9s las destacadas de los art\u00edculos, que aparecen repetidas en los listados. Y al final el resto, que puede quedarse como est\u00e1 sin que nadie lo note.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Para localizar las pesadas no hace falta ninguna herramienta especial: casi cualquier medici\u00f3n de velocidad lista los archivos m\u00e1s grandes de una p\u00e1gina concreta, y suelen repetirse los mismos tres o cuatro en todo el sitio. Sustituir esos por versiones del tama\u00f1o correcto rinde m\u00e1s que reprocesar doscientas im\u00e1genes de art\u00edculos antiguos.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Lo que no conviene es borrar. Una imagen eliminada de la biblioteca deja un hueco en cada art\u00edculo donde estaba, y esos huecos aparecen meses m\u00e1s tarde sin que nadie recuerde la causa. Reemplazar el archivo conservando el nombre, o subir el nuevo y actualizar la referencia, cuesta algo m\u00e1s de trabajo y no rompe nada.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

Por qu\u00e9 esto aparece en la velocidad y no en el dise\u00f1o<\/h2>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

En la mayor\u00eda de las p\u00e1ginas, el elemento m\u00e1s grande del primer pantallazo es una imagen. Y como ese elemento es justo el que las m\u00e9tricas de experiencia de carga usan para decidir cu\u00e1ndo una p\u00e1gina \u00abya carg\u00f3\u00bb, el peso de esa \u00fanica foto condiciona la nota de toda la p\u00e1gina.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

De ah\u00ed que el orden de prioridades sea claro. Primero las dimensiones correctas, porque es donde est\u00e1 el ahorro grande. Despu\u00e9s el formato, que aporta ese 25% o 30% adicional. Y al final los ajustes finos de calidad, que mueven poco y consumen mucho tiempo de discusi\u00f3n.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Vale decir tambi\u00e9n qu\u00e9 no resuelve esto. Un sitio lento por un servidor saturado, por scripts de terceros o por una base de datos sin mantenimiento no mejora por cambiar de formato; las im\u00e1genes son la causa m\u00e1s frecuente, no la \u00fanica. Y una foto mal elegida, encuadrada o iluminada sigue siendo una mala foto en cualquier formato, igual que una imagen tomada de un banco de im\u00e1genes<\/a> sin relaci\u00f3n con el texto sigue siendo relleno.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

El mismo razonamiento aplica al otro gran consumidor de peso de una p\u00e1gina: con los formatos de video<\/a> las decisiones de la plataforma son igual de invisibles y el ahorro posible es bastante mayor.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Lo que envejece de todo esto es la lista de formatos: AVIF era ex\u00f3tico hace cinco a\u00f1os y hoy se sirve sin pensarlo. Lo que no envejece son las dos preguntas del principio \u2014qu\u00e9 contiene la imagen y d\u00f3nde se va a ver\u2014 y el h\u00e1bito de comprobar, en la p\u00e1gina servida, qu\u00e9 recibe de verdad el visitante. Si hay que delegar una sola cosa al servidor, que sea la conversi\u00f3n; y si hay que conservar una sola disciplina propia, que sea subir el tama\u00f1o correcto.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

Preguntas frecuentes<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\n\t\t\t\t\t
\u00bfCu\u00e1l es el mejor formato de fotos para una p\u00e1gina web? <\/div><\/span>\n\t\t\t\t\t\t\t\n\t\t\t<\/path><\/svg><\/span>\n\t\t\t<\/path><\/svg><\/span>\n\t\t<\/span>\n\n\t\t\t\t\t\t<\/summary>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

WebP, en casi todos los casos: pesa bastante menos que JPG y PNG a igual calidad y admite transparencia. Si el sitio convierte autom\u00e1ticamente, basta con subir un JPG de buena calidad y dejar que el servidor haga el resto.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/details>\n\t\t\t\t\t\t

\n\t\t\t\t\n\t\t\t\t\t
\u00bfCu\u00e1l es la diferencia entre JPG y PNG? <\/div><\/span>\n\t\t\t\t\t\t\t\n\t\t\t<\/path><\/svg><\/span>\n\t\t\t<\/path><\/svg><\/span>\n\t\t<\/span>\n\n\t\t\t\t\t\t<\/summary>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

JPG comprime descartando detalle, as\u00ed que pesa menos y sirve para fotograf\u00edas. PNG conserva todo y admite transparencia, por lo que es la opci\u00f3n para logotipos, iconos y capturas con texto.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/details>\n\t\t\t\t\t\t

\n\t\t\t\t\n\t\t\t\t\t
\u00bfPor qu\u00e9 mi foto se ve borrosa despu\u00e9s de subirla? <\/div><\/span>\n\t\t\t\t\t\t\t\n\t\t\t<\/path><\/svg><\/span>\n\t\t\t<\/path><\/svg><\/span>\n\t\t<\/span>\n\n\t\t\t\t\t\t<\/summary>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Casi siempre porque se subi\u00f3 en dimensiones menores a las que el sitio la muestra y el navegador la est\u00e1 ampliando. Tambi\u00e9n ocurre al reguardar varias veces un archivo con p\u00e9rdida, que degrada un poco en cada guardado.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/details>\n\t\t\t\t\t\t

\n\t\t\t\t\n\t\t\t\t\t
\u00bfConviene convertir las fotos a WebP antes de subirlas? <\/div><\/span>\n\t\t\t\t\t\t\t\n\t\t\t<\/path><\/svg><\/span>\n\t\t\t<\/path><\/svg><\/span>\n\t\t<\/span>\n\n\t\t\t\t\t\t<\/summary>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Si el sitio ya genera esa copia autom\u00e1ticamente, no aporta nada. Lo que s\u00ed conviene es ajustar las dimensiones al tama\u00f1o real en que se ver\u00e1 la imagen, porque ah\u00ed est\u00e1 el ahorro mayor.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/details>\n\t\t\t\t\t\t

\n\t\t\t\t\n\t\t\t\t\t
\u00bfCu\u00e1nto deber\u00eda pesar una foto en una web? <\/div><\/span>\n\t\t\t\t\t\t\t\n\t\t\t<\/path><\/svg><\/span>\n\t\t\t<\/path><\/svg><\/span>\n\t\t<\/span>\n\n\t\t\t\t\t\t<\/summary>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

No hay una cifra \u00fanica, pero una imagen de contenido suele estar bien por debajo de 200 KB y una de cabecera algo m\u00e1s. M\u00e1s \u00fatil que la cifra es la regla: ning\u00fan archivo deber\u00eda pesar m\u00e1s de lo que su tama\u00f1o en pantalla justifica.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/details>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

Subir una foto de cuatro megas a un sitio web parece inofensivo hasta que alguien mide cu\u00e1nto tarda en cargar la p\u00e1gina en un tel\u00e9fono con datos m\u00f3viles. Ah\u00ed es donde los formatos de fotos dejan de ser un detalle t\u00e9cnico y pasan a ser la causa. La parte confusa es que las gu\u00edas del […]<\/p>\n","protected":false},"author":1,"featured_media":30172,"comment_status":"open","ping_status":"open","sticky":false,"template":"elementor_theme","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-29931","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-marketing-de-contenidos"],"lang":"es","translations":{"es":29931},"pll_sync_post":{},"_links":{"self":[{"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/posts\/29931","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/comments?post=29931"}],"version-history":[{"count":10,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/posts\/29931\/revisions"}],"predecessor-version":[{"id":30216,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/posts\/29931\/revisions\/30216"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/media\/30172"}],"wp:attachment":[{"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/media?parent=29931"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/categories?post=29931"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ingenio.la\/blog\/wp-json\/wp\/v2\/tags?post=29931"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}