Загрузите файл в серверный конвертер, и произойдут три вещи. Ваш файл путешествует по сети на IP-адрес, который вы не контролируете. Процесс на этом сервере декодирует его. Затем, в зависимости от политики хранения сайта, файл лежит на диске от нескольких минут до бесконечности.
Сделайте то же самое во вкладке браузера, и файл никогда не покинет оперативную память вашей машины. Декодер работает внутри песочницы WebAssembly, обеспечиваемой движком браузера. Сеть не затрагивается никогда.
Это не разница в политике. Это разница в архитектуре. Серверный конвертер может обещать удалить ваши файлы; браузерный не может их утечь, потому что он их никогда не получает.
Архитектура
Четыре слоя обеспечивают работу клиентской конвертации:
Слой 1: Доступ к Файлам
Когда вы перетаскиваете файл во вкладку браузера, DragEvent или <input type="file"> передаёт JavaScript объект File. File — это не содержимое файла. Это ссылка: имя, размер, MIME-тип и метод (file.arrayBuffer()), который читает байты с диска в память по требованию.
Пока этот метод не вызван, ни один байт не перемещён. Файл находится в вашей файловой системе. Выбор файлов браузера — это диалог на уровне ОС; веб-страница видит только объект File, явно выбранный пользователем.
Слой 2: Определение Формата
Первые байты любого файла надёжно идентифицируют его формат. JPEG начинается с FF D8 FF. PNG начинается с 89 50 4E 47. Файл HEIC содержит бокс ftyp с брендом heic или heif на смещении 8.
Чтения заголовка файла (обычно первых 32 байт) достаточно, чтобы подтвердить, чем он является на самом деле, независимо от расширения. Эта проверка выполняется до того, как любой декодер коснётся пиксельных данных. Если заголовок не совпадает, файл немедленно отклоняется. Никаких потраченных циклов CPU, никаких запутанных сообщений об ошибках посреди декодирования.
Слой 3: Декодирование
Сырые байты становятся пикселями через декодер. Какой декодер — зависит от формата:
- JPEG, PNG, WebP, BMP: браузер поставляется с нативными декодерами для этих форматов.
createImageBitmap()передаёт сжатые байты кодеку платформы (Windows Imaging Component на Windows, Core Graphics на macOS, Skia на Linux/ChromeOS) и возвращает сырые пиксельные данные. Этот путь быстр, аппаратно ускорен там, где ОС это поддерживает, и не требует дополнительного кода. - HEIC: ни один браузер, кроме Safari, не имеет нативного HEIC-декодера. Наш конвертер включает libheif, C-библиотеку, скомпилированную в WebAssembly. Бинарный файл
.wasm(~1,2 МБ в сжатом виде) загружается один раз и кешируется. Он декодирует HEIF/HEIC-файлы в сырые RGB-пиксели полностью внутри песочницы WASM. - PDF: PDF.js (рендерер PDF от Mozilla) рендерит каждую страницу на canvas с запрошенным разрешением. Никакого серверного рендеринга. PDF никогда не покидает браузер.
Каждый декодер читает из памяти и пишет в память. Ни один не открывает сокеты. Песочница WASM, в частности, не может делать сетевые запросы: браузер не предоставляет сетевые API модулям WebAssembly. Даже если бы C-код вызвал socket(), песочница перехватила бы этот вызов.
Слой 4: Кодирование
Сырые пиксели поступают в 2D-контекст элемента <canvas>. canvas.toBlob() или canvas.toDataURL() вызывает встроенный кодер браузера для вывода в JPG, PNG или WebP. Кодер — это нативный код платформы: тот же путь кода, который ваша операционная система использует для сохранения скриншотов.
Результат — Blob, байтовый буфер в памяти. Он передаётся в ссылку для скачивания или упаковывается в ZIP-архив, создаваемый на JavaScript. Ни в какой момент ни один байт не касается сетевого сокета.
Что Обеспечивает Браузер
Веб-страницы работают внутри песочницы, которую браузер поддерживает на уровне движка. Это не вежливое соглашение. Это обеспечивается изоляцией процессов:
Процесс рендерера: движок JavaScript, DOM и среда выполнения WASM находятся в изолированном процессе без прямого доступа к файловой системе или сети. Он общается с внешним миром через IPC с процессом браузера.
Изоляция сайтов: современные браузеры помещают каждый источник в собственный процесс рендерера. Ваши файлы на file-convert-factory.org невидимы для JavaScript, работающего на любом другом домене.
Песочница WASM: модули WebAssembly видят плоский линейный буфер памяти и ничего больше. Никаких API файловой системы, никакого fetch, если он явно не импортирован из JavaScript, никакого доступа к DOM или другим API браузера. Худшее, что может сделать скомпрометированный модуль WASM — повредить собственную память и обрушить вкладку.
Серверный конвертер работает как привилегированный процесс в ОС сервера. Он может читать с диска, писать на диск, открывать сетевые соединения и порождать дочерние процессы. Модель безопасности зависит от компетентности и намерений оператора сервера. Песочница браузера зависит только от корректности движка браузера, а браузерные песочницы — одни из самых тщательно аудируемых границ безопасности в программном обеспечении.
Что Серверные Конвертеры Обещают (и Чего Нет)
Серверные конвертеры не являются злонамеренными по своей сути. Многие управляются командами с добрыми намерениями. Проблема структурная:
- Шаг загрузки — это копия. Ваш файл теперь существует в двух местах. Вы контролируете одну копию. Кто-то другой контролирует другую.
- Удаление — это обещание. «Мы удаляем файлы через 24 часа» означает доверие к строке лога, cron-задаче, системе резервного копирования и каждому сотруднику с доступом к серверу. Ничто из этого нельзя проверить снаружи.
- Метаданные путешествуют с файлом. EXIF-данные вашей фотографии (GPS-координаты, серийный номер камеры, временная метка) являются частью байтов файла. Если файл загружен, метаданные загружены. Наше руководство по приватности EXIF подробно описывает, что именно там находится и как это удалить. Краткая версия: каждый конвертер на этом сайте удаляет метаданные, потому что он декодирует пиксели и перекодирует их, отбрасывая всё, что не является данными изображения.
- HTTPS защищает канал, а не конечную точку. TLS шифрует загрузку при передаче. Он ничего не делает с тем, что происходит с файлом после прибытия.
Гарантия приватности браузерного конвертера уже, но сильнее. Она гласит: ваши файлы не покидают ваше устройство, потому что для этого нет пути в коде. Это проверяемо. Откройте вкладку Network в DevTools во время конвертации файла. Вы увидите однократную загрузку WASM-бинарника, а затем ничего. Ноль загруженных байтов. Никаких запросов к /api/convert. Никакого WebSocket-трафика. Конвертация происходит полностью внутри процесса рендерера.
Проверьте Сами
Вам не нужно верить кому-либо на слово. Откройте Chrome DevTools (F12), переключитесь на вкладку Network и конвертируйте файл на любой странице инструмента. Единственная сетевая активность, которую вы увидите:
- HTML, CSS и JavaScript страницы: загружаются один раз при первом посещении.
- WASM-бинарник (для HEIC-конвертеров): загружается один раз, затем кешируется.
- Запросы аналитики (если вы их не заблокировали).
Никакие данные файлов не покидают браузер. Content-Length каждого запроса измеряется в килобайтах, а не мегабайтах. Это может независимо проверить любой, кто умеет открывать DevTools.
То же самое нельзя сказать о серверном сервисе. Вы загружаете файл, получаете результат и верите, что сервер его удалил.
Связанные Инструменты
Каждый конвертер на этом сайте следует этой архитектуре. Конвейер (сброс, валидация, декодирование, кодирование, скачивание) работает идентично на всех 23 инструментах:
- HEIC в JPG · HEIC в PNG · HEIC в WebP
- JPG в PNG · JPG в WebP · JPG в ICO
- PNG в JPG · PNG в WebP · PNG в ICO
- WebP в JPG · WebP в PNG · WebP в ICO
- BMP в JPG · BMP в PNG · BMP в WebP · BMP в ICO
- PDF в JPG · PDF в PNG · PDF в WebP
- Изображение в Текст (OCR): та же клиентская архитектура, запускает Tesseract в WASM
Технические подробности о песочнице WASM см. в нашем объяснении WebAssembly. Для более глубокого анализа метаданных, которые несут ваши фотографии, руководство по приватности EXIF показывает, как читать и удалять их побайтово.
