Does ChatGPT Send Your Entire Prompt? I Checked the Network Tab

I kept seeing browser extensions claim they “protect your prompts before they reach ChatGPT.”

But changing the text visible in the chat box does not prove that anything was protected.

The important question is:

What did the browser actually send?

So I tested a live ChatGPT request using synthetic data and inspected the outgoing payload.

Why visual masking is not enough

Imagine entering this into ChatGPT:

OPENAI_API_KEY=sk-proj-EXAMPLE1234567890abcdefghijkl
CUSTOMER_EMAIL=[e-mail]

Both values are fake and were created specifically for this test.

A privacy extension might blur these values, replace them in the interface, or display a warning.

That looks reassuring, but it does not prove that the original text was removed from the outgoing request.

The browser’s Network panel provides a better way to check.

Never use a live credential for this experiment. Use an unmistakably synthetic value that cannot access a real account.

How to inspect the request

Open a fresh ChatGPT conversation and follow these steps:

1. Open Chrome DevTools with F12 or Ctrl + Shift + I.
2. Select the Network panel.
3. Filter the requests using Fetch/XHR.
4. Keep DevTools open before sending the message.
5. Enter a prompt containing your unique fake value.
6. Press Send.
7. Open the new conversation or message request.
8. Inspect its Payload or Request data.
9. Search for the fake marker you entered.

ChatGPT’s endpoints and request formats change, so the exact request name may differ. You are looking for the request created when the message is submitted.

What happens without masking

If the outgoing request contains the original value:

sk-proj-EXAMPLE1234567890abcdefghijkl

then that value was transmitted by the browser.

Deleting the message afterwards does not change what was already present in the request.

This is expected behavior: ChatGPT needs to receive a prompt before it can answer. The problem is that logs, configuration files, stack traces, and support messages often contain information we did not intend to share.

What send-time masking looks like

With OmniShield active, the message sent to ChatGPT contained placeholders instead:

OPENAI_API_KEY=[OMNI_MASK_OPENAI_KEY_...]
CUSTOMER_EMAIL=[OMNI_MASK_EMAIL_...]

Here is the actual result from the live test:

ChatGPT could still understand that the prompt contained an API key and a customer email. It did not need the original values to explain the configuration.

That distinction matters:

Changing what appears after submission is cosmetic. Changing the outgoing payload is protection.

Checking the outgoing request

I also captured the browser request created during the same test.

The request was sent to ChatGPT’s conversation endpoint. I checked its decoded payload against the exact synthetic API key and email entered earlier.

Neither raw value was present. The OmniShield placeholders were present.

The evidence above was generated from the real browser request captured during the test. It is not a manually invented example or a screenshot containing a live credential.

Test typed text too

Many privacy tools focus exclusively on paste events.

That works when someone pastes an entire log or configuration file. But users also:

• Type sensitive values manually
• Edit pasted content inside the composer
• Combine text from multiple sources
• Submit using Enter instead of clicking Send

A useful test should cover all these workflows.

I recommend checking:

• A pasted fake API key
• A manually typed fake key
• Submission with Enter
• Submission with the Send button
• Multiple sensitive-data types in one prompt
• Ordinary text that should not be modified

That last test is important. A security tool that constantly masks harmless identifiers will become frustrating very quickly.

Run a negative control

Disable the extension and repeat the same experiment.

The raw synthetic marker should now appear in the outgoing request.

If the request looks identical with protection enabled and disabled, one of three things may be happening:

1. You inspected the wrong request.
2. The synthetic value did not match a detector.
3. That submission path is not protected.

This is why testing matters more than trusting a feature list.

“Runs locally” does not answer everything

Local processing is a valuable privacy property. It means the extension does not need to upload your prompt to its own server for classification.

But “local” does not explain when protection happens.

A local tool might:

• Sanitize text only after clicking a separate button
• Scan clipboard paste events
• Display a warning without changing the message
• Block submission completely
• Replace sensitive values when the message is submitted

These are different workflows.

None is automatically right for everyone. A company may prefer blocking and manual approval. An individual developer may prefer automatic masking with readable placeholders.

The important thing is understanding which behavior you are getting.

What this experiment does not prove

This test shows what was present in the specific request I captured.

It does not prove that:

• Every submission path is protected
• Every sensitive-data pattern will be detected
• The extension itself has no vulnerabilities
• A supported website will never change
• The AI provider handles received data in a particular way

Browser extensions depend on websites that evolve constantly. A test that passes today should be repeated after significant interface or request changes.

Still, inspecting the outgoing request turns a vague privacy promise into a concrete question:

Is my fake secret in the payload or not?

Why I ran this test

I’m building OmniShield, a Chrome extension that masks API keys, credentials, and PII locally before supported AI-chat requests are sent.

That gives me an obvious bias.

So do not trust the marketing copy—including mine. Use synthetic data, open DevTools, and verify the behavior yourself.

I published the complete walkthrough here:

Does ChatGPT Send Your Entire Prompt? Check the Network Tab

You can also try the free browser-based prompt sanitizer without installing anything.

If you test this with another privacy extension, I’d be interested to hear what appears in the outgoing request.