API keys, personal data, contracts, private source code, and other sensitive files need a higher bar before you hand them to an online service.
Contents (6)
Online converters, compressors, transcription tools, and document viewers are convenient. But before choosing a file, ask a simpler question first: is this a file you are allowed to hand to an external service at all?
The risk is not that every online tool is unsafe. The problem is using a service without understanding where the file is processed, how long it is stored, who operates the service, or what its terms allow.
Files you should usually avoid uploading
1. Files containing API keys, passwords, tokens, or private keys
Treat authentication material as the highest-priority category.
Examples include:
.envfiles- API keys
- database connection strings
- SSH private keys
- PGP or RSA private keys
- access tokens
- password lists
- credentials files such as
credentials.json
GitHub's secret-scanning documentation covers many of these credential types because exposing them can lead to unauthorized access, not just disclosure of the file's contents.
If you only need to format or convert a file, there is usually no reason to give a third-party service live credentials. Remove the sensitive values from a copy, or process the file locally.
2. Customer, employee, or partner personal data
Be cautious with files containing information such as:
- names and email addresses
- phone numbers and addresses
- customer lists
- resumes
- HR evaluations
- payroll data
- support histories
For work data, convenience should not override company policy, contractual obligations, or approved-vendor requirements.
A free tool may be technically capable of processing a file and still be the wrong place to put regulated, contractual, or confidential information.
3. Contracts and unpublished business material
A document does not need personal data to be sensitive.
Examples include:
- contracts
- quotes and pricing
- cost data
- sales reports
- business plans
- unreleased investor materials
- product specifications
- meeting notes
The contents may contain negotiation positions, internal assumptions, or information that has value precisely because it is not public.
Before uploading this kind of file for conversion or summarization, check whether the service is approved for the information you are handling.
4. Private source code and configuration files
Source code can reveal more than algorithms. It can expose internal hostnames, architecture, comments, environment names, endpoints, and operational assumptions.
Configuration files deserve special attention:
.env
config.yaml
settings.json
credentials.json
*.pem
*.key
Do not assume a file is harmless because it "only contains config." If you need outside tooling, reduce the input to the smallest necessary excerpt and remove secrets first.
5. Anything that would be a serious problem if it became public
A useful first-pass test is:
If this exact file appeared on the public internet tomorrow, would that create a problem?
If the answer is yes, do not upload it to an unfamiliar service until you understand the service's processing and data-handling model.
This is not a replacement for formal information classification, but it is an effective personal sanity check.
"Online" does not tell you where processing happens
Web tools can use very different architectures.
Server-side processing
The browser uploads the file, the service processes it on a server, and the result is returned.
This can be appropriate for heavy workloads or server-side AI features, but you should understand:
- where the file is sent
- whether and how long it is stored
- whether the content can be used for training or other secondary purposes
- whether another provider receives it
- how deletion works
Browser-side processing
JavaScript or WebAssembly can process the file on the device after the web app loads.
Browser APIs such as FileReader.readAsText() allow a page to read a user-selected local file without first uploading it to a server.
But there is an important limitation: reading a file locally does not prove that the page never sends it anywhere. JavaScript can still make outbound requests.
How to evaluate a browser-based tool
For a sensitive file, you can go beyond the privacy copy and inspect behavior.
Check the Network panel
Open your browser developer tools and watch the Network panel while you load or process a harmless test file.
Look for new requests to APIs or unfamiliar domains after the file is selected.
Check the Content Security Policy
Content Security Policy (CSP) lets a site restrict the destinations that scripts, images, forms, and other browser features may use.
A restrictive policy can reduce the number of paths through which a page can make outbound connections. It is not a complete security guarantee, but it is useful evidence about the site's architecture.
oka-project's Markdown Viewer and Yomu use browser-side document processing for their core Markdown workflows and restrict unnecessary outbound connections with CSP.
Local processing does not solve every security problem
Keeping a document out of a conversion server can reduce exposure, but other risks remain:
- malware on the device
- a browser extension with broad page access
- clipboard exposure
- shared browser profiles
- accidental sharing by the user
Local processing is a way to remove one data path. It is not a substitute for endpoint security, access control, or organizational policy.
A five-question check before uploading a file
Before using an online tool, ask:
- Does this file contain secrets or confidential information?
- Is processing performed locally or on a server?
- If a server is used, is the retention period clear?
- Does the service explain third-party sharing or secondary use?
- Is this service permitted for the data under my organization or contract?
If you cannot answer one of these questions, do not use the original sensitive file as a test case. Use a sanitized copy or choose a local workflow.
Frequently asked questions
Is it okay to upload a `.env` or config file if I only want to convert it?
Treat files containing credentials as high risk even when the job is trivial. A format conversion does not require handing live API keys, private keys, tokens, or connection strings to an unknown service. Use a sanitized copy or a local workflow instead.
Is a browser-side tool automatically safe?
No. Processing a file in the browser can remove the need for a conversion server, but that alone does not prove the page never sends data elsewhere. Network requests, browser extensions, malware on the device, clipboard exposure, and accidental sharing remain separate risks.
How can I check whether a tool sends my file anywhere?
Use a harmless test file and watch the browser's Network panel while loading and processing it. Also inspect the site's Content Security Policy to see which outbound destinations are allowed. Neither check is a complete security audit, but together they provide more evidence than a privacy claim alone.
What should I do when I am not sure whether a file is safe to upload?
Use the simplest first-pass rule: if the exact file becoming public tomorrow would create a serious problem, do not upload the original to an unfamiliar service until you understand how that service processes and retains data. Use a sanitized copy or an approved local workflow.
Bottom line
The most important decision happens before you compare features: decide whether the file should leave your device in the first place.
API keys, private keys, personal data, contracts, confidential business material, and private source code should not be casually uploaded to unknown services. Remove sensitive data when possible, use approved services when required, and prefer local processing when the job does not need a remote server.