Cookies de estadística y publicidad
Usamos cookies de estadística y de publicidad, y ambas van a Google. Si rechazas, para ti no cambia nada visible.Ir a la página de privacidad
Aquí puedes convertir ICO a BMP gratis y sin cuenta: suelta el archivo arriba y en un par de segundos tienes el resultado listo para descargar. La conversión ocurre en tu propio navegador, así que el archivo no se sube nunca. Funciona igual en Windows, macOS y Linux que en iPhone y Android, y sigue funcionando aunque cortes la conexión.
Hasta 100 archivos a la vez. Mezclar formatos no es problema.
Se convierten uno tras otro y vuelven juntos en un ZIP.
ICO a BMP
ICO 139 KB → BMP 450 KB 3.2× más grande
ICO 7 KB → BMP 450 KB 64.4× más grande
ICO 3 KB → BMP 450 KB 175.2× más grande
Ambos vienen de Microsoft y se diseñaron juntos. El formato de icono original ni siquiera envolvía una imagen aparte: cada entrada llevaba una cabecera de mapa de bits, sus datos de color y una máscara de un bit que decía qué píxeles dejar en paz. Un ICO era, literalmente, mapas de bits metidos en un directorio con una plantilla encima.
Después los dos caminos se separaron. Los iconos ganaron un canal alfa de ocho bits con Windows XP y la posibilidad de llevar una carga PNG con Vista, que es lo que usan hoy los archivos modernos en sus entradas grandes. El mapa de bits que escribe este conversor es la línea base de 24 bits, que nunca ganó ninguna de las dos cosas. Convertir de uno al otro es por tanto un paso atrás en capacidades, emprendido porque algo al otro lado lo necesita.
El codificador escribe 24 bits por píxel: ocho de azul, ocho de verde, ocho de rojo y nada más. Existe una variante de cabecera BMP que define un canal alfa y existen archivos que la usan, pero casi nada la lee con fiabilidad, que es exactamente el problema de fiabilidad que uno intenta evitar eligiendo BMP.
Así que la transparencia tiene que ir a algún sitio antes de que corra el codificador, y el ajuste de color de fondo decide a cuál. El blanco es el valor por defecto. Elige el color de la superficie sobre la que se va a dibujar el mapa de bits: el fondo del banner de un instalador, el color del panel de una pantalla empotrada. En un icono de prueba con esquinas transparentes el resultado leyó 255,255,255 en la esquina, que es correcto y es también la respuesta equivocada si el panel es gris oscuro.
No es un defecto y es la razón entera de que exista BMP. Cada píxel ocupa tres bytes sea lo que sea, así que el tamaño del archivo es aritmética y no un resultado: el ancho por tres, redondeado hacia arriba a múltiplo de cuatro, por el alto, más 54 bytes de cabecera.
Para un cuadrado de 256 píxeles eso son 768 bytes por fila y 196.608 bytes de píxeles, es decir 196.662 en total. Medido contra el icono de prueba de 8.471 bytes del que salió, el mapa de bits es más de veintitrés veces mayor. Si el destino tiene límite de tamaño, haz esa multiplicación antes de convertir y no después.
El mayor de todos. La descodificación la hace el lector de iconos de tu navegador, que devuelve la entrada más grande del directorio: comprobado construyendo un archivo con dibujos de 16, 32, 48 y 256 píxeles en cuatro colores distintos y convirtiéndolo con el directorio escrito en tres órdenes diferentes. Salió el dibujo de 256 píxeles todas las veces.
Las entradas menores no se escriben en ningún sitio y no hay ajuste que llegue hasta ellas. Si el programa que vas a alimentar quiere un mapa de bits de 32 píxeles y el icono contiene una entrada de 32, un editor de iconos como GIMP exporta esa capa directamente, y ese resultado es mejor que reducir el dibujo de 256.
Dos detalles que conviene saber si vas a leer los bytes en lugar de abrir el archivo. Un BMP guarda sus filas desde la parte inferior de la imagen hacia arriba, y guarda cada píxel como azul, luego verde, luego rojo. Las dos cosas están en la especificación y las dos sorprenden con regularidad a quien analiza uno por primera vez.
Cada fila se rellena además hasta un múltiplo de cuatro bytes, lo que importa en anchos impares: un mapa de bits de 33 píxeles de ancho tiene 99 bytes de color por fila y uno de relleno, con lo que la fila almacenada mide 100. A 256 píxeles la fila son 768 bytes y no hace falta relleno, que es una de las razones por las que los mapas de bits del tamaño de un icono se manejan bien a mano.
Porque leer uno no requiere descodificador. Un microcontrolador que gobierna una pantalla pequeña puede copiar bytes del archivo al búfer de vídeo con un bucle y un desplazamiento de cabecera; meter un descodificador de PNG en ese firmware significa meter un descompresor, un asignador de memoria y un analizador de bloques en un aparato que quizá tenga 32 KB de RAM.
El mismo razonamiento vale para los recursos de un instalador, para controles antiguos de Windows que cargan recursos a través de las funciones de mapa de bits de la propia plataforma, y para pruebas automatizadas que comparan imágenes byte a byte sin un códec de por medio. En todos esos casos la previsibilidad vale muchísimo más que el tamaño.
Los dos formatos guardan píxeles sin pérdida, y este camino no tiene control de calidad porque no hay nada que intercambiar. Cada valor de color que sobrevive al aplanado es bit a bit el que guardaba el icono, así que convertir el mismo archivo dos veces da una salida idéntica y no hay pérdida generacional de la que preocuparse si más adelante vuelve a pasar por el paso.
Las dos cosas que sí se pierden son el canal alfa, sustituido por el color de fondo, y las demás entradas del contenedor. Ninguna es recuperable después a partir del mapa de bits, que es el argumento para conservar el archivo de icono original en lugar de reemplazarlo.
Si el destino es software moderno con una preferencia declarada y no un requisito duro, un PNG es dos órdenes de magnitud más pequeño y mantiene la transparencia. El mismo icono de prueba ocupó 1.737 bytes como PNG frente a 196.662 como mapa de bits: una diferencia lo bastante grande como para justificar un correo preguntando si BMP hace falta de verdad.
Cuando la respuesta es que sí —firmware, un guion de instalación, una prueba con comparación a nivel de byte—, el mapa de bits es lo correcto y su tamaño es el precio de poder leerse sin descodificador. Déjalo escrito en el mensaje de confirmación del repositorio, porque un archivo de 200 KB para un icono pequeño le parece un error a quien lo revise después.
La página ofrece un ancho máximo, igual que el resto de conversiones de imagen, y actúa solo sobre el ancho: el alto sigue la proporción. En este par se usa poco, porque la fuente ya está limitada a 256 píxeles y casi ningún destino que exija BMP quiere una imagen menor de la que tiene.
Sí sirve en un caso concreto: cuando el panel o el recurso al que va destinada tiene una anchura fija menor. Reducir aquí a 128 divide el archivo por cuatro, porque el peso de un mapa de bits crece con el área y no con el lado. Pedir más de lo que hay no tiene sentido en la otra dirección: ampliar añade bytes y ni un detalle.
Suelta el conjunto entero. Cada archivo se descodifica, se aplana sobre el mismo color de fondo y se escribe por separado, y todo vuelve en un ZIP. Un fondo común para toda la tanda suele ser justo lo que estos destinos necesitan, porque las imágenes se están componiendo sobre una única superficie.
Comprueba las dimensiones del resultado en lugar de darlas por hechas. Los conjuntos de iconos acumulados durante años mezclan entradas que llegan a 256 píxeles con otras que se quedan en 32, y los mapas de bits heredan esa dispersión, con un factor de sesenta y cuatro entre los tamaños de archivo de los dos extremos.
No viaja ningún metadato del icono al BMP. La conversión descodifica la imagen a píxeles y escribe el archivo desde ellos, así que no hay EXIF, ni XMP, ni perfil de color incrustado: hay una cabecera, la dimensión, la profundidad de color y las filas.
Para el destino habitual de este par eso es una virtud y no una carencia. Un firmware que copia bytes a una pantalla, un recurso de instalador o una prueba que compara imágenes byte a byte quieren precisamente un archivo sin nada que interpretar. Lo que hay que tener presente es la consecuencia en color: sin perfil incrustado, los valores se interpretan como los entienda el programa que abra el archivo, y esa es una razón más para fijar el color de fondo mirando el aparato de destino y no la pantalla en la que estás trabajando.
La descodificación y el ensamblado del mapa de bits ocurren dentro de tu navegador, así que el archivo no sale del equipo. En este par eso tiene además una ventaja práctica evidente: no hay que esperar a que suba un archivo de 8 KB para descargar uno de 200 KB.
El plan gratuito admite hasta 100 MB por archivo y cien archivos por tanda, sin cuenta y sin recuento diario. Para material de este tamaño esos números no son un límite, son la confirmación de que un conjunto completo de recursos cabe de una vez.
| ICO | BMP | |
|---|---|---|
| Nombre completo | Icono de Windows | Mapa de bits de Windows |
| Extensión de archivo | .ico | .bmp, .dib |
| Tipo de medio | image/x-icon | image/bmp |
| Compresión | Sin pérdida — no se descarta nada | Sin comprimir |
| Publicado por primera vez | 1985 | 1987 |
| Publicado por | Microsoft | Microsoft |
| Licencia | Publicado, no estandarizado | Publicado, no estandarizado |
| Situación actual | De nicho | Antiguo, aún se lee en todas partes |
| Profundidad de bits | 8 | 8 |
| Color que puede describir | RGB, paleta indexada | RGB, paleta indexada |
| Imagen más grande | 256 px por lado | — |
| Se abre en el navegador | Todos los navegadores | Todos los navegadores |
| Considerado en su lugar | PNG, SVG | PNG, TIFF |
BMP no tiene canal alfa. Un archivo ICO con transparencia sale con esas zonas rellenas —blancas si no indicas otra cosa— y ningún ajuste de BMP devuelve la transparencia.
GIMP lee tanto ICO como BMP, así que puedes comparar el resultado con el original sin un segundo programa.
BMP guarda las muestras en crudo, así que el archivo crece bastante sin ganar nada. Solo tiene sentido cuando un programa del otro lado no acepta ICO, que suele ser la razón para hacerlo.
Los dos apuntan a trabajos distintos: ICO a la web y BMP a mover datos entre programas. Conviene sopesarlo antes, porque la razón de ser de uno suele ser la razón por la que el otro resulta incómodo.
ICO es el formato de Microsoft, publicado en 1985. Registra 8 bits por canal.
BMP viene de Microsoft y es de 1987. Microsoft Paint, GIMP y IrfanView lo leen.
No. Esta conversión ocurre por completo en tu navegador, así que el archivo no sale de tu dispositivo. Puedes comprobarlo tú: abre la pestaña de red de las herramientas de desarrollo y convierte algo. Verás la propia página y las peticiones de estadística y publicidad con las que se paga este servicio, y ni una sola que lleve tu archivo. El motor de este par concreto es jSquash, compilaciones en WebAssembly de los códecs de imagen de referencia; tu navegador lo descarga una vez y lo guarda.
Sí. Sin cuenta, sin marca de agua y sin cupo diario que se gaste: se ejecuta en tu propio equipo, así que puedes volver tantas veces como quieras. El navegador procesa archivos de hasta 100 MB, 100 a la vez. jSquash se descarga en tu equipo y se ejecuta allí, y por eso no hay contador.
BMP comprime, así que se pierden datos. Con el ajuste por defecto no se aprecia; si quieres asegurarte, sube la calidad. El formato de destino no admite transparencia, así que las zonas transparentes se rellenan con el color de fondo.
BMP no tiene canal alfa. Un archivo ICO con transparencia sale con esas zonas rellenas —blancas si no indicas otra cosa— y ningún ajuste de BMP devuelve la transparencia.
BMP guarda las muestras en crudo, así que el archivo crece bastante sin ganar nada. Solo tiene sentido cuando un programa del otro lado no acepta ICO, que suele ser la razón para hacerlo.