Conversor de kilobytes a megabytes

Convierte kilobytes (KB) a megabytes (MB) en tiempo real. Calculadora online 100 % gratuita, sin registro, con la fórmula exacta y una tabla de valores comunes.

⇄ Convertir al revés

Qué te está diciendo exactamente el resultado

La conversión de KB a MB parece trivial hasta que un formulario rechaza un archivo que, según tú, pesaba menos que el límite. Casi siempre el problema no es la aritmética, sino que dos sistemas están llamando «megabyte» a cosas distintas separadas por un 2,4 %. A la escala del kilobyte esa diferencia rara vez decide nada; lo que sí decide es entender qué mide cada cifra y dónde se aplica el tope.

El factor que aplica este conversor

El campo de resultado se calcula multiplicando por 0,0009765625, que es 1 dividido entre 1.024. Es el factor binario, el que reparte el espacio en potencias de dos porque así es como direcciona la memoria un ordenador. De ahí salen los valores de la tabla: 500 KB dan 0,488281 MB, no 0,5 MB, y hacen falta 1.024 KB para llegar a un megabyte redondo.

La consecuencia práctica es que, en esta escala, nunca redondees mentalmente a 1.000. Si trabajas con un tope de 2 MB, el número que tienes que comparar es 2.048 KB. Un archivo de 2.100 KB se pasa por 52 KB, una cantidad pequeña que basta para que el servidor devuelva un error, y el usuario que hizo la cuenta con 1.000 se queda sin entender por qué.

MB o MiB: la etiqueta correcta

Si el factor es 1.024, el nombre riguroso del resultado no es megabyte sino mebibyte (MiB). La norma IEC 80000-13 reserva el prefijo «mega» para el factor 1.000 y crea «mebi» para el factor 1.024, igual que «kibi» (KiB) para los 1.024 bytes. El conversor escribe MB porque es la etiqueta que vas a leer en la pantalla de tu sistema operativo, en el cuadro de propiedades de un archivo y en el mensaje de error de un formulario: usar la notación estricta aquí te daría un número correcto con un nombre que no casa con ninguna de las pantallas que estás mirando.

Cuando un programa te dice «2 MB» está diciendo casi siempre 2 MiB, o sea 2.048 KB. Leer la etiqueta como si fuera decimal es la forma más habitual de calcular mal por defecto, y siempre en la dirección que te hace perder tiempo.

Cuándo importa la otra convención

Hay contextos donde el megabyte sí vale 1.000.000 de bytes: las etiquetas de capacidad de los fabricantes de almacenamiento, buena parte de las herramientas del mundo Apple y los cálculos de transferencia. La diferencia se multiplica según subes de escalón, así que a partir del gigabyte deja de ser un detalle y pasa a explicar desajustes visibles. Si lo que buscas es ese lado de la historia (de dónde salen los prefijos binarios, por qué un disco anunciado como 1 TB aparece con menos capacidad, y la relación entre megabits por segundo y megabytes por segundo), lo tienes desarrollado en convertir gigabytes a megabytes. Esta página se queda en la escala pequeña, que es donde el KB y el MB se usan de verdad todos los días: adjuntos, formularios, imágenes, documentos y ficheros de texto.

Límites de adjuntos y de subida: por qué tu archivo «de 2 MB» no entra

El caso más frecuente de conversión KB a MB no es académico: alguien tiene un archivo y un límite, y quiere saber si cabe. Ahí hay tres trampas encadenadas, y ninguna es la división.

Trampa 1: el límite no se aplica a tu archivo, sino al envío

Cuando adjuntas algo a un correo, ese archivo no viaja tal cual. El correo electrónico nació como un protocolo de texto de 7 bits, así que cualquier contenido binario (una foto, un PDF, un ZIP) se transforma en caracteres imprimibles antes de salir. El límite que te anuncia el servidor se mide sobre el mensaje ya transformado, no sobre el archivo que tienes en el escritorio. Lo mismo pasa con un formulario web: el servidor limita el tamaño del cuerpo de la petición, que incluye tu archivo, los demás campos del formulario y las cabeceras que separan cada parte.

Trampa 2: Base64 y el 33 % de sobrecoste

La codificación que se usa para transportar binarios por correo se llama Base64 y funciona así: toma los bits de 3 bytes seguidos (24 bits) y los reparte en 4 grupos de 6 bits, cada uno representado por un carácter de un alfabeto de 64 símbolos. Cuatro caracteres donde antes había tres bytes significa un crecimiento exacto de 4/3, es decir, un 33,33 %. A eso se añade un salto de línea cada 76 caracteres (en torno a un 1,4 % más) y las cabeceras MIME de cada parte del mensaje. La regla práctica que conviene memorizar es multiplicar por 1,37 para pasar de archivo a envío, y dividir entre 1,37 para pasar de límite a archivo.

Trampa 3: el tope de verdad está en la configuración del servidor

En un formulario de subida, el mensaje «archivo demasiado grande» puede venir de varios sitios a la vez, y el que manda es el más restrictivo de todos. En una pila web típica se apilan al menos tres capas: la directiva del intérprete (en PHP, upload_max_filesize y, por encima, post_max_size, que tiene que ser mayor porque abarca todo el formulario), el tope del servidor web (en nginx, client_max_body_size) y cualquier proxy o CDN que haya delante. Todas esas directivas cuentan en potencias de 1.024: un valor de 2M significa 2.048 KB, y por eso la conversión correcta importa.

Al otro lado hay un límite que nadie configura y que también existe: el del gestor documental o la aplicación, que a veces recorta por número de páginas, por dimensiones de imagen o por formato, no por peso. Si un archivo de 900 KB se rechaza y el tope es de 5 MB, deja de mirar la conversión y busca la restricción real.

Qué hacer cuando no cabe

Por orden de eficacia real, y no de lo que primero se le ocurre a la gente: reducir la resolución si es una imagen o un escaneo (es la palanca que más recorta, porque el peso crece con el cuadrado de las dimensiones), reexportar el documento en vez de comprimirlo por fuera, dividir el contenido en varios envíos, y solo al final comprimir en ZIP. El ZIP es la opción que más se intenta y la que menos rinde cuando el contenido ya es una imagen o un vídeo, porque esos formatos salen comprimidos de fábrica y no queda redundancia que exprimir.

El presupuesto de bytes de una página web

En desarrollo web el kilobyte es la unidad natural de trabajo, y la conversión a MB sirve sobre todo para el titular: «esta página pesa 3,2 MB» se entiende mejor que «3.277 KB». Pero las decisiones se toman en KB, porque es la escala a la que se recorta.

Por qué 100 KB de más se notan

Una conexión no arranca a velocidad máxima. El protocolo TCP empieza con una ventana de congestión pequeña (diez segmentos, alrededor de 14 KB) y la va ampliando según confirma que los paquetes llegan. Eso significa que los primeros kilobytes de una página viajan en una ronda de ida y vuelta, los siguientes en otra, y así sucesivamente. En una red móvil con latencia alta, cada ronda adicional cuesta tiempo aunque el ancho de banda sobre. Por eso 100 KB añadidos a un recurso que bloquea el renderizado duelen mucho más que 100 KB añadidos a una imagen que se carga al final de la página.

El razonamiento útil es al revés del habitual: en lugar de exportar la imagen y ver cuánto pesa, decide primero cuánto puede pesar la página completa, reparte ese presupuesto entre HTML, CSS, fuentes, JavaScript e imágenes, y ajusta cada pieza a su cuota. Cuando un recurso se sale del presupuesto, hay que quitarlo o sustituirlo, no negociar con él.

Compresión: gzip y Brotli

El servidor puede enviar los archivos de texto comprimidos y el navegador los descomprime al vuelo. Gzip usa el algoritmo DEFLATE, que combina la búsqueda de cadenas repetidas con codificación de longitud variable. Brotli hace lo mismo con un diccionario predefinido de fragmentos habituales en la web, lo que le da ventaja precisamente en los archivos pequeños, donde no hay suficiente texto propio del que aprender.

Dos consecuencias que conviene tener claras. La primera: HTML, CSS, JavaScript, SVG, JSON y XML se benefician mucho porque repiten estructura; JPEG, PNG, WebP, AVIF, MP4 y los PDF con imágenes no, porque ya están comprimidos, y forzar la compresión solo gasta CPU. La segunda: la cifra que ves en el panel de red de un navegador tiene dos columnas, los bytes transferidos y el tamaño del recurso descomprimido. Cuando alguien dice que su CSS «pesa 180 KB» y el navegador muestra 22 KB transferidos, ambas cosas son ciertas y miden fases distintas.

Caché: los kilobytes que no se pagan dos veces

Un archivo con una caducidad larga y un nombre versionado (el típico app.8f2c1d.js) se descarga una vez y se reutiliza en las visitas siguientes sin pedir permiso al servidor. Ahí el reparto de KB cambia de sentido: conviene separar lo que cambia en cada despliegue de lo que no, porque un único archivo gigante obliga a volver a descargarlo entero cada vez que se toca una línea. Y hay un coste invisible que también se mide en bytes: cada petición arrastra cabeceras, así que cargar treinta iconos sueltos de 2 KB no cuesta 60 KB, cuesta 60 KB más treinta rondas de peticiones con sus cabeceras.

Optimización de imágenes explicada por el mecanismo

Las imágenes se llevan la mayor parte del peso de casi cualquier página y de casi cualquier adjunto. Aquí no hay tablas de «peso típico» que valgan, porque el peso de una imagen no depende de lo que representa sino de tres variables que puedes controlar.

De dónde sale el peso: píxeles, profundidad y entropía

Sin comprimir, una imagen ocupa ancho × alto × bytes por píxel. Una foto de 1.000 × 1.000 píxeles en color de 8 bits por canal son 3.000.000 de bytes, es decir, 2.930 KB o 2,86 MB. Si le añades canal alfa (transparencia) pasan a ser 4 bytes por píxel y sube a 3,81 MB. Ese es el punto de partida que después la compresión reduce.

De ahí salen las dos palancas grandes. La primera es duplicar o dividir las dimensiones: pasar de 2.000 a 1.000 píxeles de ancho no reduce el peso a la mitad, lo reduce a la cuarta parte, porque el número de píxeles va con el cuadrado. La segunda es la complejidad de la imagen: una fotografía con hojas, texturas o grano tiene mucha variación entre píxeles vecinos y ofrece poco donde ahorrar; una captura de pantalla, un logotipo o un gráfico con áreas planas de color se comprime muchísimo mejor, porque hay largas tiradas de píxeles idénticos.

Qué hace cada formato

La decisión, resumida en una frase: si la imagen es una fotografía, un formato con pérdida; si tiene texto, líneas o áreas planas, uno sin pérdida o vectorial. Elegir PNG para una foto es la forma más rápida de convertir 200 KB en 2 MB sin ganar nada visible. Si quieres el detalle de esa comparación, lo tienes en JPG, PNG y WebP: cuál usar en cada caso, y el procedimiento de recorte en cómo comprimir imágenes sin perder calidad.

Las palancas que de verdad bajan los KB

Ordenadas por rendimiento: servir la imagen al tamaño en que se ve (con srcset y sizes el navegador elige la variante que necesita, y en un móvil eso puede ser una cuarta parte de los píxeles); bajar la calidad del exportador hasta el punto en que el ojo no distingue, que en fotografía suele estar bastante por debajo del máximo; quitar los metadatos (perfiles de color, datos EXIF, miniaturas incrustadas), que en fotos de móvil pueden sumar decenas de KB; y aplazar la carga de lo que está fuera de pantalla con loading="lazy", que no reduce el peso total pero sí los KB que hacen falta para que la página sea usable.

La imagen más ligera es la que no se descarga. La segunda más ligera es la que se descarga exactamente al ancho que ocupa en pantalla. Todo lo demás (elegir formato, ajustar calidad, limpiar metadatos) son mejoras sobre esas dos decisiones, no sustitutos.

Tipografías, CSS y JavaScript: los KB que cuestan más caros

Fuentes web

Un archivo de fuente contiene el dibujo vectorial de cada glifo, más las tablas de métricas, espaciado entre pares y ligaduras. Una familia completa con alfabetos cirílico, griego y vietnamita arrastra miles de glifos que un sitio en castellano nunca va a pintar. Las dos medidas que recortan de verdad son el formato WOFF2 (usa compresión Brotli específica para fuentes y deja muy atrás a los formatos anteriores) y el subconjunto: generar un archivo solo con los caracteres que usas, o declarar unicode-range para que el navegador descargue únicamente el bloque que la página necesita. Después está la cuenta que más se olvida: cada peso y cada estilo es un archivo aparte. Cargar regular, medium, semibold, bold y sus cursivas son diez descargas; con dos pesos se resuelve casi cualquier diseño.

CSS y JavaScript

Minificar quita espacios, saltos de línea y comentarios, y acorta nombres internos: recorta un porcentaje apreciable antes de comprimir, y comprimir después vuelve a recortar sobre eso. El siguiente paso es eliminar lo que no se usa: reglas CSS de componentes que ya no existen y módulos de JavaScript que entran con una dependencia y nunca se llaman.

Hay una asimetría que conviene tener presente al repartir el presupuesto: 100 KB de JavaScript cuestan más que 100 KB de imagen. La imagen se descarga y se decodifica sin bloquear la interacción. El JavaScript hay que descargarlo, analizarlo, compilarlo y ejecutarlo en el hilo principal, que es el mismo que responde a los toques y a los clics. En un móvil de gama media esa diferencia se nota en la sensación de que la página «está ahí pero no reacciona».

Documentos ofimáticos y PDF

DOCX, XLSX y PPTX son archivos ZIP

Cambia la extensión de un .docx por .zip, ábrelo y verás la respuesta a «por qué pesa tanto». Dentro hay varios archivos XML con el texto y los estilos, y una carpeta media con las imágenes incrustadas. El XML comprime muy bien, así que un documento de solo texto, por largo que sea, se queda en el orden de decenas de KB. Todo lo que sobrepase eso son las imágenes, y en particular las que se pegaron desde una cámara o un móvil y después se redujeron arrastrando la esquina: el documento sigue guardando el original completo, aunque se vea del tamaño de un sello.

De ahí que la opción «comprimir imágenes» de los procesadores de texto, que reexporta cada imagen a la resolución de destino y descarta las zonas recortadas, suela rebajar más que cualquier compresor externo. Lo mismo vale para las hojas de cálculo: el peso desproporcionado viene de formatos aplicados a columnas enteras, de miles de filas vacías con estilo y de imágenes incrustadas, no de los números.

Por qué un PDF escaneado pesa tanto

Un PDF generado desde un procesador de textos guarda texto real: caracteres, posiciones y una referencia a la fuente (a veces incrustada, lo que añade su peso). Un PDF escaneado no guarda nada de eso: guarda una imagen por página. Su peso responde a la fórmula de cualquier imagen: área × resolución al cuadrado × profundidad de color. Un A4 a 300 puntos por pulgada son unos 8,7 millones de píxeles por página; a 600 ppp, cuatro veces más. Si además se escanea en color de 24 bits un documento que es texto negro sobre papel blanco, se están gastando tres canales para representar dos tonos.

Las decisiones que lo arreglan son, por orden: escanear a la resolución mínima que conserve la legibilidad, elegir escala de grises o blanco y negro cuando el original no tiene color, y activar el OCR cuando lo que se necesita es buscar dentro del documento (el OCR añade una capa de texto invisible y suma pocos KB, mientras que permite luego tratar el archivo como texto). Si tu punto de partida es un PDF y lo que quieres es el texto editable, tienes el procedimiento en cómo convertir PDF a Word sin perder el formato.

Sectores, clústeres y el «tamaño en disco»

Abre las propiedades de un archivo pequeño en Windows y verás dos cifras distintas: «Tamaño» y «Tamaño en disco». No es un error. El sistema de archivos no reparte el espacio byte a byte, sino en bloques llamados clústeres o unidades de asignación, que agrupan varios sectores físicos. En NTFS el valor por defecto en la mayoría de volúmenes es de 4 KB, y en formatos pensados para tarjetas y discos grandes puede ser bastante mayor.

La regla es simple: un archivo siempre ocupa un número entero de clústeres. Un archivo de 1 KB ocupa 4 KB y desperdicia 3 KB. Uno de 5 KB ocupa dos clústeres, 8 KB, y desperdicia 3 KB. A ese hueco se le llama espacio interno desaprovechado, y en la escala del kilobyte es donde más duele: proporcionalmente, un archivo de 1 KB desperdicia el 300 % de su tamaño, mientras que un archivo de 4 MB desperdicia como mucho 4 KB, o sea, una milésima parte.

El caso práctico donde esto explota son los directorios con miles de archivos diminutos: caché de miniaturas, archivos de configuración, mensajes de correo guardados uno por archivo, repositorios de código con sus objetos. Mil archivos de 2 KB suman 2.000 KB de contenido (1,95 MB) pero ocupan 4.000 KB en disco (3,91 MB): el doble. Cuando copias ese directorio, además, la lentitud no viene del volumen de datos sino del número de operaciones. Empaquetarlo en un solo ZIP o TAR antes de moverlo cambia el orden de magnitud del tiempo.

Hay una excepción que conviene conocer: NTFS guarda los archivos muy pequeños, de unos cientos de bytes, dentro del propio registro de la tabla maestra de archivos, sin asignarles ningún clúster. Por eso a veces un archivo de 200 bytes marca un tamaño en disco de 0.

Texto, CSV y logs: cuando los KB se pueden calcular de cabeza

El texto plano es el único contenido cuyo peso puedes predecir con exactitud antes de generarlo, y por eso es el mejor terreno para practicar la conversión a MB. En codificación UTF-8, que es la habitual, cada carácter del alfabeto latino básico ocupa 1 byte; las vocales acentuadas, la eñe, los signos de apertura y el símbolo del euro ocupan 2 bytes; y los emojis suelen ocupar 4. A cada línea hay que sumarle el salto: 1 byte en Linux y macOS, 2 en Windows por la pareja retorno de carro más avance de línea.

Estimar un CSV antes de exportarlo

Toma una fila representativa, cuenta sus caracteres, añade las comas y el salto de línea, y multiplica por el número de filas. Si una fila de un listado de pedidos ocupa unos 60 bytes y vas a exportar 50.000 filas, el resultado son 3.000.000 de bytes, es decir, 2.930 KB o 2,86 MB según el factor binario. Con esa cuenta hecha antes de pulsar «exportar» sabes si el archivo va a entrar en el formulario de importación de destino, y si no, cuántas filas por lote tienes que partir.

Logs y rotación

Un registro de servidor crece de forma lineal y muy predecible: cada petición escribe una línea de estructura casi idéntica. Ese parecido entre líneas es exactamente lo que explota un compresor, así que un log comprimido queda en una fracción pequeña del original, mucho mejor que cualquier formato binario. La práctica estándar (rotar por tamaño o por fecha y comprimir los archivos ya cerrados) se apoya en esa propiedad. Cuando dimensiones el espacio, calcula el pico diario de líneas por el tamaño medio de línea y conviértelo a MB: es la única manera de saber cuántos días de histórico te caben.

Cómo medir el peso real antes de subir nada

Casi todos los errores de «no me cabe» se evitan mirando el número correcto en el sitio correcto.

En el escritorio

En Windows, botón derecho sobre el archivo y Propiedades: el dato que tienes que comparar con el límite es Tamaño, no «Tamaño en disco», que es el espacio ocupado por clústeres y puede ser mayor. En macOS, Obtener información, con el mismo criterio. En una terminal de Linux o macOS, ls -l muestra el tamaño exacto en bytes, du -h el espacio ocupado y du --apparent-size -h el tamaño lógico. Si trabajas con carpetas enteras, du -sh * ordena la búsqueda del culpable en un segundo.

En el navegador

Abre las herramientas de desarrollo, pestaña Red, y recarga con la caché desactivada. La columna de tamaño distingue los bytes transferidos por la red de los del recurso descomprimido, y la fila de totales del pie te da el peso de la página completa. Ordena por tamaño descendente y tendrás la lista de recortes por orden de rentabilidad. Si además quieres saber cuánto tarda esa carga en tu conexión real, el test de velocidad de internet te da el otro lado de la ecuación.

Desde el móvil

Es donde más fácil resulta enviar sin querer archivos enormes, porque la galería muestra miniaturas y oculta que detrás hay fotos de muchos megapíxeles. Antes de adjuntar, entra en la información del archivo dentro del gestor de archivos o de la galería, donde aparece el tamaño. Si vas a enviar varias fotos, comprueba si la aplicación ofrece una opción de tamaño reducido en el momento de adjuntar: reescala antes de subir y recorta el envío de forma notable. Y si el móvil guarda en HEIC y el destinatario necesita JPEG, ten en cuenta que la conversión suele aumentar el peso, porque HEIC comprime mejor a igualdad de calidad.

Medir cuesta diez segundos y ahorra el ciclo de subir, esperar, recibir el error, adivinar el motivo y repetir. Cuando un límite se expresa en MB y tu archivo en KB, haz la conversión con 1.024 antes de intentarlo, no después.

Ejemplos resueltos paso a paso

1. Una imagen de 850 KB

Divide entre 1.024: 850 ÷ 1.024 = 0,830078125 MB, que redondeado son 0,83 MB. Si lo hubieras calculado con 1.000 te saldría 0,85 MB, un 2,4 % de más. A esta escala la diferencia es cosmética, pero el hábito de dividir entre 1.024 es el que te salva en el siguiente ejemplo.

2. Un formulario con tope de 2 MB

El tope en kilobytes es 2 × 1.024 = 2.048 KB. Un archivo de 1.980 KB entra con 68 KB de margen. Uno de 2.100 KB se rechaza, aunque «dos mil cien» suene a «poco más de dos megas». Si el rechazo llega igualmente con 1.980 KB, el tope real está en otra capa (el servidor web o un proxy) y no lo arreglas recortando 20 KB más.

3. Un adjunto contra un límite de 20 MB

El límite se aplica al mensaje codificado, así que divide entre 1,37: 20 ÷ 1,37 = 14,6 MB de archivo real, unos 14.950 KB. Si tienes dos archivos de 8 MB cada uno, suman 16 MB reales y en torno a 21,9 MB de envío: no pasan. Con uno solo por correo sí, o comprimiendo el segundo lo suficiente.

4. Presupuesto de una página

Objetivo: 1 MB para la primera carga, es decir, 1.024 KB. Un reparto de trabajo razonable: HTML 20 KB, CSS 40 KB, fuentes 80 KB (dos pesos en WOFF2 con subconjunto latino), JavaScript 180 KB e imágenes el resto, 704 KB. Con una imagen principal de 150 KB quedan 554 KB para todo lo demás. Cuando entra un recurso nuevo, sale otro: el presupuesto solo funciona si es un número fijo y no una aspiración.

5. Mil archivos pequeños

Mil archivos de 2 KB dan 2.000 KB de contenido, que son 1,95 MB. Con clústeres de 4 KB, cada archivo ocupa un clúster entero: 4.000 KB, o 3,91 MB en disco. El doble. Y si el destino es una subida por red, el tiempo lo marcarán las mil operaciones, no los dos megas.

6. Un escaneo que hay que adelgazar

Un documento de diez páginas escaneado en color a 600 ppp tiene, por página, cuatro veces más píxeles que a 300 ppp y tres canales de color para un contenido que es texto en negro. Bajar a 300 ppp divide el número de píxeles entre cuatro; pasar a escala de grises elimina dos de los tres canales. Las dos medidas juntas cambian el orden de magnitud del archivo sin tocar la legibilidad, y son reversibles solo volviendo a escanear, así que conserva el original hasta comprobar el resultado.

Errores frecuentes al pasar de KB a MB

Redondear a 1.000 «porque está cerca». Lo está, pero los topes de subida no perdonan: 2.048 y 2.000 son números distintos y el servidor compara contra el primero.

Confundir el tamaño con el tamaño en disco. Para un límite de subida cuenta el primero; para saber cuánto espacio libre te queda, el segundo.

Sumar KB de archivos y comparar con el límite del envío. Falta el sobrecoste de la codificación, que en correo ronda el 37 %.

Comprimir en ZIP lo que ya está comprimido. Con JPEG, PNG, MP4 o PDF con imágenes el ahorro es casi nulo y añade un paso al destinatario.

Mezclar bits y bytes. Las velocidades de conexión se expresan en megabits por segundo y los archivos en megabytes: no son la misma unidad ni se comparan directamente.

Fiarse del peso que aparece en la vista previa. La miniatura de una galería o el tamaño que muestra un editor mientras editas no son el archivo final; el número bueno es el del archivo ya guardado o exportado.