How to Use AI and Online Tools Without Leaking Private Data

Before you paste text into an AI chatbot or upload a file to a free online tool, assume it leaves your device and may be stored. The safest habits are to remove personal details first, prefer tools that run entirely in your browser, and never paste secrets such as API keys or tokens. This guide explains what actually happens to your data and gives a checklist to run before every paste.

What happens when you paste or upload

Most web tools fall into two groups. Server-based tools send your text or file over the internet to the provider, process it there, and return the result. Your data may be logged, kept for a period, reviewed by staff for abuse or quality, or, for some AI services, used to improve models depending on the plan and settings. Browser-based (client-side) tools run the code on your own device. The page downloads once, and the work happens locally.

The rules differ by provider, plan (consumer versus business or API), and setting. Do not rely on a blog post, including this one, for a specific retention period. Read the data-usage and privacy pages of the service you use, and check them again when you change plans.

A practical way to test a tool: load the page, turn off your internet connection, and try it. If it still works, your data is not being sent anywhere for that task. All NiceToolkit tools process text and files in your browser; the currency converter is the exception because it needs to fetch exchange rates.

What to redact before you paste

Replace real values with placeholders that keep the structure, so the AI or tool can still help.

• Emails and phone numbers: use user@example.com and 555-0100.
• Names and addresses: use “Customer A” and “123 Example Street”.
• API keys, passwords, tokens, private keys: never paste them. Use API_KEY_HERE. If one has already been pasted, treat it as exposed and rotate it.
• Government and financial IDs: social security, passport, bank account and card numbers should not leave your device.
• Internal URLs, hostnames and customer data in logs: search for IP addresses, domains and IDs before sharing a log.
• Unreleased business details: contract terms, pricing and source code that is not yours to share.

Use find-and-replace in a text editor, and read the redacted version once more before pasting. The regex tester helps you build a pattern for something like email addresses and see what it matches on sample text before you rely on it.

Remove hidden data from photos

A photo can carry more than pixels. Phones usually write EXIF metadata into the file: the date and time, the camera or phone model, and often the GPS coordinates of where you stood. Some platforms strip this on upload; others do not, and a file sent by email or posted on a forum may arrive intact.

Before you share a photo of your home, your child, or an item you are selling, drop it into the image metadata remover. It re-saves the image without the hidden fields, in your browser, so the original never leaves your device. Check the result by opening the file’s properties and confirming that location and camera fields are gone. Note that metadata removal does not blur faces, street signs or the view from a window; those are still in the picture.

Check a JWT locally

A JSON Web Token (JWT) is the long string, in three dot-separated parts, that many apps use to prove you are logged in. The first two parts are only encoded, not encrypted, which means anyone who has the token can read its contents. The format is defined in RFC 7519.

That makes pasting a live token into an unknown website risky: if the site stores it, someone could use it to act as you until it expires. If you must inspect a token, use a decoder that runs locally, such as the JWT decoder, and prefer an expired or test token. Decoding shows the header and claims, such as expiry time. It does not prove the token is valid, because that needs the signing key, and you should never enter a production secret into any web page. If you pasted a live token somewhere you did not trust, sign out and revoke sessions.

Password hygiene that matches current guidance

NIST’s digital identity guidelines, SP 800-63B, shifted the advice many of us grew up with. In summary, the guidelines say that:

• Length beats complexity. User-chosen passwords should be at least 8 characters, and systems should allow at least 64.
• Services should not force arbitrary composition rules (one capital, one symbol) or periodic password changes without evidence of compromise.
• New passwords should be checked against lists of known-breached and commonly used passwords.
• Pasting into password fields should be allowed, which supports password managers.

In practice: use a password manager, make each password unique, and generate them rather than inventing them. The password generator creates random passwords of a length you choose. Use the password strength checker to see why a pattern is weak, but test a similar example, not your real password. For how services should store passwords, the OWASP Password Storage Cheat Sheet explains salted, slow hashing.

Verify downloads without uploading them

When software publishes a checksum (such as SHA-256), you can confirm your download was not corrupted or swapped. A hash is a fixed-length fingerprint of the file, and any change gives a different result. Use the hash generator to compute MD5, SHA-1, SHA-256 or SHA-512 on a file or text locally, then compare it with the value on the publisher’s site. Prefer SHA-256 or SHA-512; MD5 and SHA-1 are fine for catching accidental corruption but are not safe against deliberate tampering. A hash is not encryption, so do not use it to “hide” data.

A redaction example

Say you want an AI assistant to explain an error in a log. The raw line is:

2026-11-07 09:14:03 ERROR user=jane.doe@acme-corp.com ip=203.0.113.45 token=eyJhbGciOi... db=prod-customers.internal failed to connect

A safe version keeps the structure and drops everything identifying:

DATE TIME ERROR user=USER_EMAIL ip=IP_ADDRESS token=REDACTED db=DB_HOST failed to connect

The assistant can still explain the connection failure. It does not need the real email, address, token or hostname. If you paste hundreds of lines, replace values in bulk and then search the result for “@”, “token”, “key” and “password” before sending.

Common mistakes that cause leaks

• Pasting a whole config file. Files such as .env or deployment settings almost always hold secrets. Paste only the relevant lines.
• Sharing a screenshot with the address bar showing. URLs can include session IDs or access tokens in the query string, which OWASP warns about in its note on information exposure through query strings.
• Forgetting document properties. Word and PDF files can store the author’s name, company and edit history. Export a fresh PDF or clear properties before sharing.
• Trusting “incognito”. Private browsing windows keep local history off your device. They do not change what a website does with the data you submit.
• Reusing one password. One leaked password from a small forum can open your email if you used it there too.

Pre-paste checklist

1. Do I need to paste this at all? A smaller excerpt is often enough.
2. Is it redacted? No names, emails, IDs, keys, tokens or internal addresses.
3. Does the tool run locally? Try it offline, or check its privacy page.
4. What are the data settings? For AI services, find the setting and policy on whether chats are used for training or retained, and choose accordingly.
5. Is the file clean? Remove photo metadata and check document properties such as author and revision history.
6. Is it permitted? Employer rules, client contracts and privacy laws may forbid sharing certain data with third-party services.
7. If a secret slipped through, rotate it now. Deleting the chat does not make a leaked key safe.

What about your own team or clients?

If you handle other people’s data, the rules above are the minimum, not the limit. Ask your employer or client which AI and file tools are approved, and keep a short written list. Where regulations such as GDPR or HIPAA apply, sending personal data to a third-party service can require a contract and a legal basis, so ask the person responsible for compliance before you paste anything about customers or patients. Browser-based tools reduce the exposure, but they do not replace that conversation.

The short version

Redact first, prefer local tools, keep secrets out of every text box, and remove hidden data from files before sharing. These habits take a minute and prevent problems that take weeks to clean up.