> JPG | encode | data-uri <
// Codifica fotos JPG / JPEG a strings Base64 y URIs de datos — con EXIF, coeficientes DCT y calidad preservados
Suelta el JPG / JPEG aquí o haz clic para seleccionar
Haz clic para explorar archivos JPG / JPEG
Idéntico bit a bit
Tu JPEG nunca se recomprime. Los coeficientes DCT, las tablas de cuantización y los metadatos EXIF sobreviven al round-trip sin cambios.
Procesamiento local
Las fotos se codifican en el navegador con FileReader + btoa(). Sin subidas, sin servidor, sin analítica sobre los bytes de tu imagen.
Listo para pegar
Copia una URI data:image/jpeg;base64,… conforme al estándar directamente en HTML, CSS, correos o payloads de API JSON.
// FAQ — JPG A BASE64
P: ¿Qué es la codificación JPG a Base64?
R: Reescribe los bytes binarios de un archivo .jpg / .jpeg como una cadena segura en ASCII usando el alfabeto Base64 (RFC 4648). El texto resultante puede incrustarse en HTML, CSS, correos, cuerpos JSON o en cualquier otro canal solo texto sin necesitar un archivo aparte. Fundamentalmente, el JPEG subyacente no se recodifica — cada coeficiente DCT, tabla de cuantización, tabla de Huffman y marcador de metadatos EXIF/IPTC/XMP se preservan.
P: ¿Cómo codifico un JPG a Base64?
R: Arrastra un archivo .jpg o .jpeg a la zona de subida (o haz clic para explorar). La herramienta lo abre con FileReader.readAsDataURL(), que produce una URI data:image/jpeg;base64,/9j/4AAQSkZ… lista para pegar. Elige URI de datos para incrustarla directamente en <img>, o Solo payload Base64 si tu API espera el payload crudo sin el prefijo data:image/jpeg;base64,.
P: ¿Codificar un JPG a Base64 degrada la calidad de la imagen?
R: No. Base64 es una transformación reversible de binario a texto — no una recodificación. La compresión original del JPEG (sea cual sea el nivel de calidad, el modo de submuestreo y las tablas de Huffman con las que se guardó) se preserva byte a byte. Si decodificas el Base64 de vuelta a archivo, su hash SHA-256 coincide con el original. La única pérdida de calidad que podría afectar a un JPEG ya ocurrió cuando se guardó por primera vez desde un editor; Base64 no añade ninguna más.
P: ¿Por qué toda cadena Base64 de JPG empieza por <code>/9j/</code>?
R: Los dos primeros bytes de todo JPEG son el marcador Start-Of-Image FF D8, seguidos de un marcador de aplicación como FF E0 (JFIF) o FF E1 (EXIF). Cuando codificas en Base64 los primeros 3 bytes FF D8 FF siempre obtienes /9j/. Así que cualquier cadena que empiece por /9j/4AAQ (JFIF) o /9j/2wC (muchas cámaras de smartphone) es de forma fiable un JPEG — una comprobación útil al depurar.
P: ¿Cuánto más grande queda un JPG tras codificarlo en Base64?
R: Base64 añade alrededor de un 33 % de sobrecoste: tamaño_base64 = 4 × ⌈tamaño_bytes / 3⌉. Una foto de 250 KB se convierte en ~340 KB de texto. Como los JPEG ya están comprimidos, gzip/Brotli sobre la cadena Base64 solo recupera ~10 %. Para imágenes inline, mantén la fuente por debajo de ~5 KB (≈ 6,8 KB codificados) o inflarás tu HTML/CSS y empeorará el first-paint.
P: ¿Cómo incrusto un JPG como Base64 en HTML?
R: Pega la URI de datos completa en el atributo src: <img src="data:image/jpeg;base64,/9j/4AAQSkZ…" alt="cover">
No se hace ninguna petición HTTP — el navegador decodifica el Base64 y muestra la foto inmediatamente. Por eso las miniaturas JPEG inline son populares en secciones hero above-the-fold, firmas de correo e informes HTML de un único archivo.
P: ¿Cómo codifico JPG a Base64 en JavaScript, Node, Python, PHP, Go?
R:
JavaScript (navegador): new FileReader() + .readAsDataURL(jpgFile) → el result es la URI de datos
Node.js: fs.readFileSync('photo.jpg').toString('base64')
Python: base64.b64encode(open('photo.jpg','rb').read()).decode()
PHP: base64_encode(file_get_contents('photo.jpg'))
Go: base64.StdEncoding.EncodeToString(jpgBytes)
Ruby: Base64.strict_encode64(File.read('photo.jpg'))
Bash: base64 -w0 photo.jpg (GNU) o base64 -i photo.jpg -o out.txt (macOS)
P: ¿Se preservan mis datos EXIF al codificar un JPG en Base64?
R: Sí, por defecto. El segmento EXIF (modelo de cámara, fecha/hora, coordenadas GPS, objetivo, exposición, balance de blancos, orientación) vive dentro del JPEG como marcadores APP1. Como Base64 es una transformación bit a bit, los marcadores sobreviven intactos — cuando la imagen se decodifica de vuelta, los EXIF quedan exactamente como estaban. Si la privacidad importa (coordenadas GPS, números de serie), elimina los EXIF antes de codificar con una herramienta como exiftool -all= o una re-exportación por canvas del navegador, porque Base64 por sí mismo no los quitará por ti.
P: ¿Cuándo debo usar JPG → Base64 en lugar de un JPG como archivo aparte?
R: Usa URIs de datos Base64 de JPEG cuando:
• la imagen es pequeña (< 5 KB) y crítica para el first paint
• vas a enviar una foto dentro de un cuerpo JSON de API, una mutación GraphQL o un frame WebSocket
• estás construyendo un correo HTML autocontenido, un informe o una exportación PDF que no puede depender de URLs externas de CDN
• serializas una foto en una columna TEXT de base de datos (cuando no puedes usar un BLOB)
Prefiere una URL .jpg normal cuando la imagen es grande, se reutiliza en muchas páginas o necesita sus propias cabeceras de caché a largo plazo.
P: JPG vs JPEG — ¿son formatos diferentes?
R: No. .jpg y .jpeg son simplemente extensiones de archivo distintas para el mismo formato (Joint Photographic Experts Group). Los antiguos límites de nombre 8.3 de Windows forzaban extensiones de 3 letras, por eso se impuso .jpg. Los sistemas modernos aceptan ambas. El tipo MIME siempre es image/jpeg, y el prefijo de URI de datos Base64 siempre es data:image/jpeg;base64, — nuestra herramienta trata las dos extensiones de forma idéntica.
P: ¿Es la codificación Base64 una forma de compresión de imagen?
R: No — es justo lo contrario. El propio JPEG ya está comprimido con codificación DCT + Huffman (logrando una reducción de 10–20× respecto a los datos de píxel en crudo). Base64 vuelve luego a hacer el archivo un ~33 % más grande a cambio de ser seguro en ASCII. Aun así debes usar Base64 porque algunos canales (atributos HTML, cadenas JSON, correos, URLs) no pueden transportar binario en crudo. Pero no esperes ahorro de tamaño por ello; de hecho, valora siempre aplicar gzip/Brotli encima del texto Base64.
P: ¿Puedo codificar un JPEG a un payload Base64 URL-safe para usarlo en una URL?
R: Sí — cambia a nuestro codificador Base64url (RFC 4648 §5) que usa el alfabeto -_ en lugar de +/ y omite el padding final =, produciendo un payload seguro para soltarlo en un query string o un JWT. Los payloads estándar en Base64 de un JPEG suelen tener cientos de KB y rompen muchos límites de longitud de URL (2–8 KB dependiendo del navegador/servidor), así que enlazar a un archivo casi siempre es mejor idea que URL-encodear la foto entera.
P: ¿Qué tamaño de JPG puedo codificar antes de que mi navegador se quede sin memoria?
R: La codificación se hace con FileReader en streaming y luego se llama a btoa() sobre el resultado. Los navegadores de escritorio modernos manejan entradas de 100–200 MB sin problemas; los navegadores móviles gestionan con fiabilidad hasta ~40 MB antes de tener presión de memoria. Para imágenes realmente enormes (exportaciones JPEG de RAW de cámaras de formato medio), considera un codificador del lado del servidor o un procesado por chunks — nuestra herramienta te avisa si tu foto supera los 100 MB.
P: JPG → Base64 vs PNG → Base64 — ¿cuál debería usar?
R: Usa JPG → Base64 para fotografías, carretes de cámara, imágenes de redes sociales y cualquier cosa con degradados suaves donde la compresión JPEG al 80–90 % de calidad sea aceptable. Una foto 1080p típica pesa ~200 KB en JPEG frente a ~2 MB en PNG. Usa PNG → Base64 para iconos, logos, capturas, diagramas y cualquier cosa con transparencia o bordes nítidos. Mezclar ambos: un JPG Base64 para la foto hero más un PNG Base64 para el icono superpuesto nítido es un patrón habitual.