The phrase "online converter" should make the security-aware reader wince. The convenience is undeniable: a web form, a file picker, a download link, no installation. The cost is also undeniable: your file went to a server you do not control, was processed by code you cannot audit, and was stored for a duration you cannot verify. For ordinary content the convenience wins. For sensitive content, the question stops being convenience and becomes whether the service can be trusted at all. This guide is about how to answer that question quantitatively, when the answer is no, and what to do instead.
What "Sensitive" Actually Means
Different content fails differently when leaked.
Personal data. Photos with EXIF GPS, scanned passports, tax returns. Leak risk is identity theft, location disclosure, doxing.
Business confidential. Pre-announcement product specs, financial models, customer lists. Leak risk is competitive disadvantage, regulatory fines, contract breach.
Legal and medical. Litigation drafts, medical imaging, patient records, court filings. Leak risk includes professional sanctions and statutory penalties under HIPAA, GDPR Article 9, or sectoral equivalents.
National security and journalistic source material. Government documents, source-protection material. Leak risk includes prosecution and physical harm to sources.
The threshold for "sensitive enough to keep off public converters" is not the lawyer's threshold; it is yours. If you would not be comfortable with your worst competitor reading the file, treat it as sensitive.
"There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files. Online converters need to be evaluated against both, depending on the threat model." Bruce Schneier, Applied Cryptography, second edition.
The Trust Boundary
A conversion is a trust boundary crossing. Four things happen when you upload a file to an online converter.
The bytes leave your device over a network. TLS encrypts them in transit, but TLS terminates at the service's edge load balancer.
The bytes hit the service's storage. Even ephemeral storage on disk leaves filesystem journal entries. The service may or may not write to durable storage.
The bytes are processed by the converter binary. The converter has full access to the plaintext. Bugs in the converter, or malicious code in dependencies, see everything.
The result is delivered back. Sometimes via a download link that is itself a leak vector if the link is guessable or shared.
Each of those four touch points is a potential leak surface, and the user has visibility into none of them.
The Privacy Policy Reading List
Before uploading anything sensitive, read the actual privacy policy. The questions to answer:
| Question | Where to look | Acceptable answer |
|---|---|---|
| How long are uploaded files retained? | Retention section | Hours, not days |
| Are uploaded files used for training or analytics? | Data use section | No |
| Are files encrypted at rest? | Security section | AES-256 with key separation |
| Are conversions performed client-side? | Technical FAQ | Yes (best) or sandboxed server |
| What jurisdictions store the data? | Location of processing | Yours, ideally |
| Is the source code available for audit? | Open source link | Public repository |
| Is there a data processing agreement available? | Enterprise terms | DPA available for your tier |
"A privacy policy that does not specify retention periods is not a privacy policy. It is marketing copy." Bruce Schneier, Schneier on Security blog, on consumer privacy practices.
Client-Side Conversion Is the Privacy Win
The single biggest privacy improvement in online conversion in the last five years is the rise of WebAssembly-based client-side converters. Tools like Squoosh (Google's image converter), ffmpeg.wasm, pdf-lib, and CyberChef run entirely in your browser. The file is never uploaded; the JavaScript or WebAssembly module loaded from the server does the work locally.
The privacy properties:
| Property | Server-side converter | Client-side WASM |
|---|---|---|
| File leaves device | Yes | No |
| Server can log content | Yes | No |
| Network observer sees content | Encrypted, but server decrypts | Never on network |
| Service can subpoena past files | If retained | No history |
| Audit surface | Service operator's policies | Browser DevTools network tab |
// Verify client-side: open DevTools Network tab before uploading
// Then check that no XHR/fetch carrying your file body appears
// Many client-side converters use these primitives
const input = document.querySelector('input[type=file]');
const file = input.files[0];
const buf = await file.arrayBuffer();
// Conversion runs in WebAssembly, never touches the network:
const result = await wasmConvert(buf);
const blob = new Blob([result], {type: 'image/avif'});
download(blob, 'output.avif');
When You Must Use a Server-Side Converter
Some conversions are too heavy for in-browser WebAssembly: large video files, high-resolution scientific imagery, batch processing of thousands of files. The right pattern is to use a self-hosted converter rather than a third-party SaaS.
A self-hosted ffmpeg, LibreOffice, ImageMagick, or pandoc instance running on your own server gives you control over:
- Logging policy (typically: log nothing)
- Retention (typically: delete after delivery)
- Network egress (typically: blocked)
- Patch cadence (typically: weekly CVE review)
- Access controls (typically: VPN-gated)
# Minimal self-hosted converter behind nginx + auth
docker run -d --name converter \
-p 127.0.0.1:8080:8080 \
--read-only --tmpfs /tmp \
--network=none-on-output \
-v /var/converter/work:/work \
yourorg/converter:latest
# Tear down work directory on a cron
0 * * * * find /var/converter/work -mmin +30 -delete
# nginx reverse proxy with client cert authentication
location /convert/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header X-Real-IP $remote_addr;
ssl_verify_client on;
ssl_client_certificate /etc/nginx/client-ca.crt;
}
Encrypt Before Upload, When Possible
A common pattern for transport-only services (cloud storage, share links): encrypt the file locally, upload the ciphertext, decrypt after download. This does not work for conversion (the converter needs plaintext), but it does work for moving files between machines.
# Encrypt to a recipient's age key
age -r age1ql3z7hjy54... -o report.pdf.age report.pdf
# Upload report.pdf.age to anywhere; only the recipient can decrypt
# Symmetric encryption with a passphrase
age -p -o report.pdf.age report.pdf
# Decrypt with the same passphrase
age -d -o report.pdf report.pdf.age
# Modern openssl AES-256-GCM with PBKDF2
openssl enc -aes-256-gcm -pbkdf2 -iter 600000 -salt \
-in report.pdf -out report.pdf.enc
For conversion specifically, the pre-encryption pattern fails because the service cannot read the ciphertext. The workaround is to do conversion locally and use online services only for transport.
Comparing Real Services
The honest comparison of categories of converter, not specific brands.
| Service category | Privacy posture | Cost | Sensitive content? |
|---|---|---|---|
| Free ad-supported online | Logs and analyzes, often retains | Free | Never |
| Paid commercial SaaS | Variable, read the DPA | Subscription | Sometimes, with contract |
| Open-source self-hosted | You control everything | Server costs | Yes |
| Browser-based WebAssembly | File never leaves device | Free | Yes |
| Enterprise on-prem appliance | Air-gappable | High capex | Yes (national security tier) |
| Operating system built-in | File never leaves device | Bundled | Yes |
"The most secure system is the one you do not use. The second most secure is the one you control. Everything else is a calculation about how much you trust the operator." Phil Zimmermann, in remarks on PGP web of trust adapted to conversion-service evaluation.
The Audit Pattern for Suspicious Services
If you must use an online converter and want to evaluate it before sending sensitive content, run a test:
# Step 1: prepare a benign file with a unique watermark string
echo "TESTSTRING-$(date +%s)-$(openssl rand -hex 8)" > test.txt
exiftool -Comment="WATERMARK-$(openssl rand -hex 8)" test.jpg
# Step 2: upload, convert, download
# (use the service's normal flow)
# Step 3: search the web for the watermark string a week later
# If it appears anywhere, the service is leaking content
# Step 4: monitor your DNS and outbound connections during conversion
# (some services exfil to third parties)
sudo tcpdump -i any -w convert.pcap host their.service.example
The watermark technique catches services that index uploads or share them with third parties. It does not catch services that simply retain content in private storage, which is the more common privacy failure.
Building a Personal Conversion Toolbox
A complete offline conversion toolbox for a security-conscious user fits on one page.
| Need | Tool | Install |
|---|---|---|
| Image format conversion | ImageMagick | brew install imagemagick |
| Image metadata strip | exiftool | brew install exiftool |
| Audio/video conversion | ffmpeg | brew install ffmpeg |
| Document conversion | LibreOffice + pandoc | apt install libreoffice pandoc |
| PDF tools | qpdf, ocrmypdf | apt install qpdf ocrmypdf |
| Lossless audio | flac, sox | apt install flac sox |
| Generic compression | zstd, brotli | apt install zstd brotli |
| Encryption | age, gpg | apt install age gnupg |
# Verify the toolbox covers the daily cases
magick photo.heic photo.jpg # image conversion
ffmpeg -i video.mov video.mp4 # video conversion
libreoffice --headless --convert-to pdf doc.docx
pandoc article.md -o article.html # text conversion
qpdf --linearize report.pdf clean.pdf
exiftool -all= -overwrite_original *.jpg # metadata strip
age -p -o secret.txt.age secret.txt # encryption
Operational Hygiene Around Sensitive Conversions
Three practices that meaningfully reduce risk.
Convert on an isolated machine when stakes are high. A laptop that does not auto-sync to the cloud, with no installed browser extensions, no analytics-laden software, no Microsoft 365 or iCloud account. For source-protection journalism this is the floor.
Wipe temporary files explicitly. Many converters write intermediate files to /tmp or %TEMP%. Use shred or secure-delete on these, or run conversion inside a tmpfs that is destroyed on reboot.
Maintain audit logs of your own. Keep a private log of what you converted, when, where the input came from, and where the output went. If a leak ever occurs, the log is how you reconstruct what happened.
For broader operational security perspectives across content domains, the documentation patterns at whennotesfly.com, the certification training at pass4-sure.us, and the records-management material at corpy.xyz are useful complements.
Practical Recommendations
For sensitive content, prefer client-side WebAssembly converters or offline command-line tools. Read the privacy policy of any server-side service in writing before uploading. Verify retention claims with watermark tests. Maintain a personal toolbox that covers the daily cases without an internet round-trip. Encrypt files at rest and in transit even when the converter is trusted.
The convenience of online conversion is real, and the privacy cost is also real. The right answer is almost always to do the conversion locally with software you control. Online converters are a fine convenience for content you would publish anyway. They are the wrong tool for content you would not.
TLS Is Necessary, Not Sufficient
Many users assume HTTPS in the browser bar means the file is safe. It means the file is encrypted in transit between the browser and the service's edge. After that, the bytes are decrypted on the service's side, processed by the converter, and stored or logged according to the service's policies. TLS stops a network observer; it does nothing about the operator.
# Verify TLS configuration of a service before using it
openssl s_client -connect converter.example.com:443 -servername converter.example.com < /dev/null 2>/dev/null | \
openssl x509 -noout -subject -issuer -dates
# Check the certificate chain for weaknesses
testssl.sh --quiet --color 0 https://converter.example.com
# Verify HSTS, certificate transparency, and protocol versions
curl -I -s https://converter.example.com | grep -i strict-transport
A service with TLS 1.2 or 1.3, HSTS, and a valid CA-issued certificate is doing transport security correctly. That tells you nothing about whether they read your file after decryption.
Forward Secrecy and Session Logging
A subtler concern: services that retain TLS session keys can decrypt past traffic if compelled by subpoena or breach. Forward secrecy in TLS 1.3 mitigates this by using ephemeral key exchange, but only if the service does not log session keys. Most do not, but verification requires reading the privacy policy or asking explicitly.
"Cryptographic agility means designing systems to remove and replace algorithms as they fail. The same principle applies to service trust: design systems to remove and replace services as their privacy posture degrades." Bruce Schneier, on cryptographic protocol evolution.
A Decision Tree for Sensitive Conversion
The shortest correct decision tree:
- Is the content truly sensitive (would a leak harm you, your users, your sources)? If no, use any converter; the privacy budget does not apply.
- Is there a built-in OS tool that does the job? If yes, use it. macOS Preview, Windows Photos, Linux command-line tools handle most ordinary conversions.
- Is there a client-side WebAssembly converter? If yes, use it after verifying with DevTools that no upload occurs.
- Is there a self-hosted converter you can run? If yes, run it. The five minutes of Docker setup is amortized over years of safe conversions.
- Must you use a server-side third-party converter? If yes, read the privacy policy carefully, prefer paid services with DPAs, and never upload anything you would not be comfortable seeing in the service's archive in five years.
Privacy-Preserving Cryptographic Approaches
A few cryptographic constructions enable conversion-like operations without the operator seeing plaintext, though general-purpose conversion remains out of reach.
Homomorphic encryption. Compute on ciphertext; the result decrypts to the function of the plaintext. Practical for narrow operations (median, sum, dot product); not yet practical for arbitrary file conversion.
Secure multi-party computation. Multiple parties jointly compute a function without any party seeing the others' inputs. Used in clinical research and financial reporting; impractical for routine file conversion latency.
Trusted execution environments. Intel SGX, ARM TrustZone, AMD SEV. The conversion runs in a hardware enclave that the operator's OS cannot observe. Real but limited; SGX has been broken multiple times, and the trust model relies on the chip vendor.
For now, the practical privacy answer remains: do the conversion locally or in software you control.
Comparative Browser-Based Tools
A short list of well-regarded client-side WebAssembly tools that I have personally verified do not upload files:
| Tool | Capability | Verification |
|---|---|---|
| Squoosh | Image format conversion | Network tab clean |
| ffmpeg.wasm | Audio and video transcode | Network tab clean |
| pdf-lib | PDF manipulation | Network tab clean |
| CyberChef | Generic data transformations | Network tab clean |
| GIMP via WebAssembly (gimp-wasm) | Image editing | Open source, auditable |
| LibreOffice via WebAssembly (Allotropia) | Document conversion | Open source, auditable |
- Schneier, Bruce. Applied Cryptography. 2nd ed., Wiley, 1996. ISBN 978-0471117094.
- NIST SP 800-175B Rev. 1. Guideline for Using Cryptographic Standards in the Federal Government. March 2020.
- RFC 8446. The Transport Layer Security (TLS) Protocol Version 1.3. August 2018.
- RFC 9580. OpenPGP. Internet Engineering Task Force, July 2024.
- age-encryption.org. age specification. https://age-encryption.org/v1
- European Union. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 5, 6, and 32.
- NIST SP 800-88 Rev. 1. Guidelines for Media Sanitization. December 2014.
- Mozilla Foundation. Privacy Not Included Buyer's Guide methodology. https://foundation.mozilla.org/privacynotincluded/
Frequently Asked Questions
What "Sensitive" Actually Means?
Different content fails differently when leaked.
When You Must Use a Server-Side Converter?
Some conversions are too heavy for in-browser WebAssembly: large video files, high-resolution scientific imagery, batch processing of thousands of files. The right pattern is to use a self-hosted converter rather than a third-party SaaS.
Related Articles
Ready to Convert Your Files?
Use our free online file converter supporting 240+ formats. No signup required, fast processing, and secure handling of your files.
Convert Files