Base64: как устроено кодирование, почему оно не шифрование и когда data-URL вредит скорости сайта

Коротко: что такое Base64 и где он встречается в работе с сайтом

Base64 — это способ записать любые данные (картинку, файл, строку с нестандартными символами) обычным текстом из безопасных символов. Он нужен там, где канал передачи умеет работать только с текстом: вложения в электронной почте, данные внутри XML, картинки, встроенные прямо в код страницы. Если вы видите длинную строку вида SGVsbG8= или data:image/png;base64,iVBORw0KGgo…, перед вами Base64.

Три главных факта, с которых стоит начать (по RFC 4648 и руководству MDN):

1. Base64 — не шифрование. RFC 4648 прямо пишет, что кодирование не даёт конфиденциальности: оно лишь скрывает данные визуально, например пароли. Любой может декодировать строку за секунду. Секреты в Base64 не храните и не передавайте «как защищённые».
2. Размер вырастает примерно на треть. Каждые 3 байта (24 бита) превращаются в 4 символа, поэтому результат обычно на ≈33% больше исходных данных. Для коротких строк прирост выше: слово Hello (5 байт) превращается в SGVsbG8= (8 символов).
3. Для сайта это компромисс. Встроить маленькую картинку прямо в страницу удобно, но Google в рекомендациях по изображениям отмечает, что такой способ уменьшает число HTTP-запросов, но может заметно увеличить размер страницы, поэтому использовать его стоит взвешенно.

В статье: как устроено кодирование (алфавит, заполнение «=», вариант base64url), где Base64 встречается (почта, XML, data-URL), как кодировать и декодировать (в браузере, командной строке и онлайн), проблема Unicode в JavaScript, data-URL и картинки на сайте (плюсы, минусы, влияние на скорость и SEO), безопасность, типичные ошибки, десять ошибок и PDF-чек-лист на 26 пунктов. Для быстрых операций: кодирование URL, Base64 и HTML-сущностей на tools.cetto.ru.

Основа статьи — RFC 4648 (кодировки Base16, Base32, Base64, раздел о безопасности), глоссарий MDN о Base64, страницы MDN о схеме data: и о функциях btoa и atob и рекомендации Google по изображениям в поиске (раздел о data URI). Данных о том, как именно поисковики учитывают картинки в data-URL при индексации, в этих источниках нет; в разделе про SEO я отмечаю, что подтверждено, а что нет. Все примеры кода — иллюстрации; проверяйте их в своём окружении.

Как устроено кодирование

По RFC 4648 (раздел 4): алфавит состоит из 64 символов (A–Z, a–z, 0–9, +, /) плюс символ = для заполнения, то есть на символ приходится 6 бит. Каждые 3 байта кодируются в 4 символа. Если данных не хватает до кратного 3 байтам, в конец добавляются нулевые биты и заполнение: для одного оставшегося байта получается 2 символа и ==, для двух байт 3 символа и =. Пример из стандарта: байты 0x14fb9c03d97e превращаются в FPucA9l+. Тестовый вектор: BASE64("foobar") равно Zm9vYmFy.

Правила реализации из RFC: переводы строк добавлять нельзя, если стандарт, на который вы ссылаетесь, этого не требует (ограничения MIME в 76 символов и PEM в 64 связаны с почтой); данные с символами вне алфавита декодер должен отвергать, если стандарт не разрешает их игнорировать; неиспользуемые биты в заполнении должны быть нулевыми. Из этого практический вывод: варианты нельзя смешивать. Строку base64url не получится декодировать как стандартный Base64 и наоборот; MDN для data-URL рекомендует стандартный вариант.

Размер: откуда +33%

Три байта (24 бита) превращаются в четыре символа по 6 бит, поэтому в среднем прирост около трети. Точный прирост зависит от остатка длины по модулю 3 и заполнения. Для файла в 30 КБ результат будет примерно 40 КБ. Это важно для картинок в data-URL: чем больше картинка, тем больше потеря.

Где встречается Base64

• Электронная почта (MIME). Вложения и картинки в письмах передаются как Base64: название происходит от механизма MIME Content-Transfer-Encoding (MDN). Для писем магазина это означает, что картинки в письме увеличивают его размер; почтовые клиенты и спам-фильтры по-разному относятся к встроенным картинкам: «Письма попадают в спам».
• XML и API. Двоичные данные внутри XML и JSON часто передают как Base64.
• data-URL. Встраивание небольших файлов прямо в страницу или CSS: data:image/png;base64,….
• Токены и служебные значения. Часть токенов использует base64url (по общим знаниям, без пересказа источников). Не воспринимайте «непонятную строку» как защиту.
• Куки и параметры адреса. Иногда в параметрах хранят данные в Base64; для адресов используйте URL-вариант и помните, что читаемые параметры лучше нечитаемых: «UTM-метки».

Как кодировать и декодировать

Онлайн

Для разовых задач: кодирование и декодирование Base64, URL и HTML-сущностей. Не вставляйте в онлайн-сервисы секреты: пароли, ключи, токены, персональные данные.

Командная строка

По MDN: в Linux и macOS echo -n hello | base64 даёт aGVsbG8= (ключ -n убирает перевод строки); в PowerShell: [convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello")).

JavaScript в браузере

Функции btoa() и atob() есть в окне и в воркерах: btoa("Hello") возвращает "SGVsbG8=", а atob("SGVsbG8=") — "Hello". Современные среды поддерживают также методы Uint8Array.fromBase64() и toBase64() (по MDN).

Проблема Unicode

Функции btoa и atob появились до двоичных типов и работают со «строками байтов»: каждый символ обязан иметь код меньше 256. Для кириллицы, эмодзи и любых символов выше 0xFF прямой вызов вызывает исключение (InvalidCharacterError). MDN предлагает сначала закодировать текст в UTF-8 и потом закодировать байты:

function bytesToBase64(bytes) {
  const binString = Array.from(bytes, (b) => String.fromCodePoint(b)).join("");
  return btoa(binString);
}
function base64ToBytes(base64) {
  const binString = atob(base64);
  return Uint8Array.from(binString, (m) => m.codePointAt(0));
}

const encoded = bytesToBase64(new TextEncoder().encode("Привет"));
new TextDecoder().decode(base64ToBytes(encoded));

Прямой вызов btoa("Привет") приведёт к ошибке. Для больших данных MDN упоминает асинхронные способы через FileReader и fetch с data-URL. Реализацию в рабочем коде доверьте разработчику и проверьте на реальных данных: кириллица, эмодзи, длинные строки.

data-URL: встроенные картинки на сайте

Синтаксис по MDN: data:[<media-type>][;base64],<data>. Если тип не указан, по умолчанию используется text/plain;charset=US-ASCII. Зарезервированные символы RFC 3986, пробельные и непечатаемые нужно процент-кодировать. Пример: data:text/plain;base64,SGVsbG8sIFdvcmxkIQ==.

Плюсы и минусы

Практическое правило: встраивайте только крошечные элементы (иконки, пиксели), критичные для первого экрана, а изображения товаров, баннеры и фото держите отдельными файлами с кэшированием и современными форматами: «WebP», «Оптимизация изображений». Для иконок часто лучше SVG прямо в разметке, он остаётся текстом без роста на треть.

Ошибки data-URL

MDN отмечает: неверные параметры в части media-type и опечатки в слове base64 молча игнорируются; легко забыть запятую перед данными; строки запроса не работают, потому что данные непрозрачны; длинный Base64 неудобно размещать в HTML.

Base64, скорость и SEO

• Скорость. Встроенные в HTML картинки увеличивают размер документа и задерживают отрисовку: проверьте вес страницы: размер страницы, анализ изображений, «Аудит скорости».
• Индексация картинок. По рекомендациям Google, картинки должны быть обычными элементами img со src; в разделе о data URI они лишь отмечают баланс между числом запросов и размером. Подтверждений того, что поисковики индексируют картинки из data-URL как отдельные изображения, в моих источниках нет. Все важные для поиска картинки (товары, статьи) делайте обычными файлами по адресам, с alt и описательным именем.
• Alt обязателен. Для data-картинок тоже: «Оптимизация изображений».
• Размер HTML для роботов. Раздутые документы дольше обрабатываются; про предельные размеры в моих источниках данных нет, но принцип «лёгкий HTML» остаётся.
• Адреса и параметры. Не кодируйте смысловые параметры страниц в Base64: читаемые адреса лучше для людей и аналитики: «ЧПУ».
• Метки и аналитика. Если параметры кодируются, документируйте формат и декодируйте в отчётах.

Безопасность

• Base64 не защищает данные. Кодирование не добавляет энтропии и не даёт конфиденциальности (RFC 4648): пароли, токены, ключи и персональные данные нужно защищать шифрованием и правами доступа, а не кодированием: «Надёжный пароль».
• Не доверяйте декодированным данным. То, что пришло в Base64, может содержать вредоносный код или скрытый канал: RFC отмечает, что игнорирование лишних символов может использоваться как скрытый канал передачи данных. Проверяйте формат и размер, отвергайте символы вне алфавита.
• Вывод пользовательских data-URL и HTML. Санитизируйте: «Markdown» (раздел про безопасность).
• Подозрительные строки. Длинные Base64-строки в коде страницы, шаблонах и скриптах при взломе иногда скрывают вредоносные вставки; незнакомые вставки стоит проверить (общие сведения, не пересказ источников).
• Персональные данные в параметрах и cookie в Base64 остаются персональными данными: «152-ФЗ для интернет-магазина».

Как проверить, что всё сделано правильно

1. Декодируйте и сравните. Закодируйте, затем декодируйте и убедитесь, что получилось исходное: кодирование, сравнение текстов.
2. Проверьте кириллицу и эмодзи. Именно здесь ломается btoa.
3. Проверьте вариант Base64. Для адресов и имён файлов base64url, для почты и data-URL стандартный.
4. Измерьте вес страницы до и после встраивания: размер страницы.
5. Проверьте картинки в разных браузерах и после минификации HTML и CSS.
6. Не вставляйте секреты в онлайн-сервисы.
7. Зафиксируйте решения: какие элементы можно встраивать, предельный размер, кто отвечает.

Десять частых ошибок

1. Считать Base64 шифрованием и прятать в нём пароли и ключи.
2. Встраивать большие картинки в страницы и CSS.
3. Вызывать btoa для текста с кириллицей без кодирования в UTF-8.
4. Смешивать стандартный Base64 и base64url.
5. Терять заполнение «=» или добавлять переносы строк там, где их быть не должно.
6. Забывать запятую или опечатываться в слове base64 в data-URL (ошибки молча игнорируются).
7. Не указывать alt у встроенных картинок.
8. Доверять декодированным данным без проверки формата и размера.
9. Кодировать смысловые параметры адресов и ломать читаемость и аналитику.
10. Не измерять влияние на скорость.

Что проверяю в аудите я

Встроенные картинки и служебные Base64-строки — одна из причин раздутых страниц. В SEO-аудите я измеряю вес HTML и CSS, нахожу тяжёлые data-URL, проверяю индексируемость картинок, alt и скорость, а также подозрительные вставки в шаблонах, и даю приоритетный план. Результат: PDF-отчёт на 30–50 страниц, технические задания для программистов, прогноз по трафику и заявкам и созвон, на котором я лично расскажу о найденных ошибках и отвечу на вопросы. Стоимость от 30 000 ₽, срок 3–5 рабочих дней для небольшого сайта и 7–10 для крупного магазина.

Итоговый чек-лист (короткая версия, полная в PDF)

• Понятно, что Base64 не шифрует и увеличивает размер примерно на треть.
• В data-URL встроены только крошечные элементы; важные картинки остались обычными файлами с alt.
• Используется правильный вариант Base64; для Unicode текст сначала кодируется в UTF-8.
• Секреты не кодируются «для защиты» и не вставляются в онлайн-сервисы.
• Декодированные данные проверяются; пользовательский вывод санитизируется.
• Вес страниц измерен до и после; решения зафиксированы.

Об автореВладимир Родионов

Интернет-маркетолог, частный SEO-специалист cetto.ru. 10+ лет в IT, 200+ реализованных проектов, сертификация Яндекса и Google.

Все статьи автора →Задать вопрос в Telegram →