Can I paste an API key or password into ChatGPT?

Q: Can I paste an API key or password into ChatGPT?

No. A credential pasted into any AI tool must be treated as compromised and rotated immediately — deleting the conversation does not undo the disclosure. This applies to API keys, passwords, tokens, connection strings, .env files, private keys and session cookies. When debugging, replace the secret with a placeholder such as [API_KEY]: the bug you are chasing is in the code, not in the value of the secret. Unlike other sensitive data, there is no enterprise-tier exception, because there is never a technical reason to paste a live secret.

No.

And if you already have — that key is burned. Go and rotate it now, before you finish reading this page. Everything else can wait a few minutes. That can't.

This is the one page here with no exception at the bottom. There is never a good reason to paste a live secret into a chatbot.

Why this one is different

Everything else on this site is a privacy problem. This is an access problem, and it's worse.

Leaked customer data harms someone eventually, through a chain of events. A leaked credential hands over the ability to act — right now, as you, with your permissions, from anywhere. Nobody has to breach anything. They just use it.

And the paste is rarely where it ends. That conversation is now in a chat history that can be shared by link, exported, synced to a phone, read by a browser extension, or pulled into a support ticket. Shared chat links have been indexed by search engines before. The secret you pasted at 11pm to fix one bug outlives the bug by years.

What counts as a credential

✕API keys and tokens — anything shaped like sk_live_…, ghp_…, AKIA…, xoxb-…
✕Passwords — including "temporary" ones and the shared team login nobody has changed since 2021
✕Connection strings — the username and password are right there in the middle of the URL
✕The whole .env file — the single most-pasted secret on earth. "Here's my config, why won't it connect?"
✕Private keys and certificates — SSH keys, .pem files, signing keys
✕Session cookies, bearer tokens, JWTs — short-lived is not the same as harmless
✕MFA recovery codes — the thing designed to defeat every other control you have

Do this instead

You are almost never debugging the secret. You're debugging the code around it — and that code is identical whether the value is real or fake.

Don't

Why does this connection fail?

DATABASE_URL=postgres://admin:Hunter2!Prod@prod-db.acme.internal:5432/customers
STRIPE_KEY=sk_live_9f2XkQpL8mNvR4tW

Why does this connection fail?

DATABASE_URL=postgres://[USER]:[PASSWORD]@[HOST]:5432/[DB]
STRIPE_KEY=sk_live_XXXXXXXXXXXX

Error: password authentication failed

Keep the structure — the shape of the string, the length, the prefix — and throw away the value. Then paste the actual error message, which is the part that was ever going to help.

If you already pasted one

Order matters here. People instinctively delete the chat first, which is the least useful step and wastes the minutes that count.

Rotate or revoke the credential. Right now. Not after you've finished the task it was blocking. A rotated key makes every other step academic.
Check what it did in the meantime. Pull the access logs for that key or account and look for use you can't account for — unfamiliar IPs, odd hours, calls you didn't make.
Then delete the conversation. Worth doing. Just understand it removes your copy, not theirs.
Tell your security team. Even if you rotated it in sixty seconds and nothing happened. They may need to check logs you can't see, and a reported near-miss is how controls actually get fixed.

No enterprise exception

Even on an approved enterprise tool with retention off, don't do it. Everywhere else on this site the enterprise tier genuinely changes the answer. Here it doesn't — not because the tool is untrustworthy, but because the paste was never necessary. A placeholder debugs the problem exactly as well. There's nothing to trade off.