> JPG | encode | data-uri <
// Кодируйте фотографии JPG / JPEG в строки Base64 и URI данных — EXIF, DCT-коэффициенты и качество сохраняются
Перетащите JPG / JPEG сюда или кликните для выбора
Кликните для обзора файлов JPG / JPEG
Побитово идентично
Ваш JPEG никогда не пересжимается. DCT-коэффициенты, таблицы квантования и EXIF-метаданные переживают круговой путь без изменений.
Локальная обработка
Фотографии кодируются в браузере с помощью FileReader + btoa(). Без загрузки, без сервера, без аналитики байтов вашего изображения.
Готово к вставке
Скопируйте стандартно-совместимый URI data:image/jpeg;base64,… прямо в HTML, CSS, email или JSON-нагрузки API.
// FAQ — JPG В BASE64
В: Что такое кодирование JPG в Base64?
О: Оно перезаписывает бинарные байты файла .jpg / .jpeg как ASCII-безопасную строку с использованием алфавита Base64 (RFC 4648). Полученный текст можно встроить в HTML, CSS, email, тела JSON или любой другой только-текстовый канал без необходимости отдельного файла. Критично: сам JPEG не перекодируется — каждый DCT-коэффициент, таблица квантования, таблица Хаффмана и маркеры EXIF/IPTC/XMP метаданных сохраняются.
В: Как закодировать JPG в Base64?
О: Перетащите файл .jpg или .jpeg в зону загрузки (или кликните для обзора). Инструмент открывает его через FileReader.readAsDataURL(), который производит готовый к вставке URI data:image/jpeg;base64,/9j/4AAQSkZ…. Выберите URI данных для прямого встраивания в <img>, или Только полезная нагрузка Base64, если ваш API ожидает чистую полезную нагрузку без префикса data:image/jpeg;base64,.
В: Ухудшает ли кодирование JPG в Base64 качество изображения?
О: Нет. Base64 — это обратимое бинарно-текстовое преобразование, а не повторное кодирование. Оригинальное сжатие JPEG (с каким бы уровнем качества, режимом subsampling и таблицами Хаффмана он ни был сохранён) сохраняется байт-в-байт. Если вы декодируете Base64 обратно в файл, его SHA-256 хэш совпадает с оригиналом. Единственная потеря качества, которая когда-либо может повлиять на JPEG, произошла при первом сохранении из редактора; Base64 не добавляет больше.
В: Почему каждая Base64-строка JPG начинается с <code>/9j/</code>?
О: Первые два байта каждого JPEG — это маркер Start-Of-Image FF D8, за которым следует маркер приложения типа FF E0 (JFIF) или FF E1 (EXIF). Когда вы кодируете в Base64 первые 3 байта FF D8 FF, всегда получаете /9j/. Поэтому любая строка, начинающаяся с /9j/4AAQ (JFIF) или /9j/2wC (многие смартфон-камеры) — надёжно JPEG — полезная проверка при отладке.
В: Насколько JPG увеличивается после кодирования в Base64?
О: Base64 добавляет примерно 33% накладных расходов: size_base64 = 4 × ⌈size_bytes / 3⌉. Фото 250 КБ становится ~340 КБ текста. Поскольку JPEG уже сжат, gzip/Brotli на строке Base64 восстанавливает только ~10%. Для встроенных изображений держите исходный размер ниже ~5 КБ (≈ 6.8 КБ кодированного), иначе вы раздуете свой HTML/CSS и ухудшите производительность first-paint.
В: Как встроить JPG как Base64 в HTML?
О: Вставьте полный URI данных в атрибут src: <img src="data:image/jpeg;base64,/9j/4AAQSkZ…" alt="cover">
HTTP-запрос не отправляется — браузер декодирует Base64 и немедленно отображает фотографию. Именно поэтому встроенные JPEG-миниатюры популярны в above-the-fold hero-секциях, email-подписях и одиночных HTML-отчётах.
В: Как закодировать JPG в Base64 в JavaScript, Node, Python, PHP, Go?
О:
JavaScript (браузер): new FileReader() + .readAsDataURL(jpgFile) → result — это URI данных
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) или base64 -i photo.jpg -o out.txt (macOS)
В: Сохраняются ли мои данные EXIF при кодировании JPG в Base64?
О: Да, по умолчанию. Сегмент EXIF (модель камеры, дата/время, GPS-координаты, объектив, экспозиция, баланс белого, ориентация) находится внутри JPEG как маркеры APP1. Поскольку Base64 — это побитовое преобразование, маркеры сохраняются нетронутыми — когда изображение декодируется обратно, EXIF точно такой же, как был. Если важна приватность (GPS-координаты, серийные номера), удалите EXIF перед кодированием с помощью инструмента типа exiftool -all= или повторного экспорта через canvas браузера, потому что сам Base64 не удалит его за вас.
В: Когда стоит использовать JPG → Base64 вместо JPG как отдельного файла?
О: Используйте URI данных Base64 JPEG, когда:
• изображение маленькое (< 5 КБ) и критично для first paint
• вы отправляете фото внутри тела JSON API, мутации GraphQL или кадра WebSocket
• вы строите самодостаточный HTML-email, отчёт или PDF-экспорт, который не может полагаться на внешние CDN-URL
• вы сериализуете фотографию в TEXT-колонку базы данных (когда нельзя использовать BLOB)
Предпочитайте обычный URL .jpg, когда изображение большое, повторно используется на многих страницах или нуждается в собственных долгосрочных заголовках кэширования.
В: JPG vs JPEG — это разные форматы?
О: Нет. .jpg и .jpeg — это просто разные расширения файлов для одного и того же формата (Joint Photographic Experts Group). Ранние ограничения имени файла Windows 8.3 вынуждали использовать 3-буквенные расширения, поэтому .jpg прижилось. Современные системы принимают оба. MIME-тип всегда image/jpeg, а префикс URI данных Base64 всегда data:image/jpeg;base64, — наш инструмент обрабатывает оба расширения одинаково.
В: Является ли кодирование Base64 формой сжатия изображения?
О: Нет — это противоположное. Сам JPEG уже сжат через DCT + кодирование Хаффмана (достигая 10–20-кратного уменьшения от необработанных пиксельных данных). Затем Base64 делает файл ~на 33% больше в обмен на ASCII-безопасность. Тем не менее следует использовать Base64, потому что некоторые каналы (HTML-атрибуты, JSON-строки, email, URL) не могут нести сырой бинарный код. Но не ждите экономии размера от него; фактически, всегда рассматривайте gzip/Brotli поверх текста Base64.
В: Можно ли закодировать JPEG в URL-safe полезную нагрузку Base64 для использования в URL?
О: Да — переключитесь на наш кодировщик Base64url (RFC 4648 §5), который использует алфавит -_ вместо +/ и пропускает завершающий padding =, производя полезную нагрузку, безопасную для вставки в query-строку или JWT. Сырые стандартные полезные нагрузки Base64 JPEG обычно длиной в сотни КБ и нарушают многие ограничения длины URL (2–8 КБ в зависимости от браузера/сервера), поэтому ссылка на файл почти всегда лучше, чем URL-кодирование целой фотографии.
В: Какой размер JPG можно закодировать до того, как у браузера закончится память?
О: Кодирование выполняется с помощью FileReader потоковым способом, затем btoa() вызывается на результате. Современные десктопные браузеры обрабатывают входы в 100–200 МБ без проблем; мобильные браузеры надёжно обрабатывают до ~40 МБ, прежде чем столкнуться с давлением на память. Для действительно огромных изображений (экспорты RAW-to-JPEG из среднеформатных камер) рассмотрите серверный кодировщик или chunk-based обработку — наш инструмент предупреждает вас, если ваша фотография больше 100 МБ.
В: JPG → Base64 vs PNG → Base64 — что использовать?
О: Используйте JPG → Base64 для фотографий, фотороликов, изображений соцсетей и всего с плавными градиентами, где приемлемо JPEG-сжатие 80–90% качества. Типичное фото 1080p весит ~200 КБ как JPEG vs ~2 МБ как PNG. Используйте PNG → Base64 для иконок, логотипов, скриншотов, диаграмм и всего с прозрачностью или чёткими краями. Смешение двух: Base64 JPG для hero-фотографии плюс Base64 PNG для резкой наложенной иконки — распространённый паттерн.