Does an exported n8n workflow contain my credentials?

Not the secrets. Credentials live in n8n and the export references them by id and name only, so the file reveals which account a node uses but not the password or token behind it. Anything you typed directly into a node parameter — an API key in an HTTP header field, for instance — is a different matter and is stored in the workflow itself.

What is pinData in an n8n workflow file?

Pinned data is the sample output n8n keeps when you pin a node during testing, so the workflow can be re-run without hitting the real service. It is often a real API response containing real names, emails or order records, and it travels inside the exported JSON. Strip it before sharing.

What is the safest way to show someone my workflow?

Send an image of it. A rendered diagram shows the structure, the node types and the connections — everything needed to answer "why does this branch not fire" — while carrying no parameters, no pinned data and no credential references at all.

Do Pixtex share links expire?

Yes. A share link lives for 24 hours and then the workflow behind it is deleted. Deleting one sooner requires the delete token issued when the link was created. Hosted images are the opposite: those are permanent until you remove them.

How to share an n8n workflow safely (what is actually inside the JSON)

What is actually in the file

An exported workflow is a JSON document with three interesting parts. Knowing which is which is most of the job:

nodes[].parameters — everything you typed into a node. URLs, queries, expressions, JavaScript in Code nodes, and any key you pasted into a header field. This is where inline secrets hide.
nodes[].credentials — a reference, not a secret: an id and the display name of the credential. It tells a reader that this node authenticates as Acme Prod Stripe; it does not give them the key.
pinData — sample output captured when you pinned a node during testing. This is the one people forget, and it is frequently a real API response with real customer records in it.

Checking a file before you send it

Two greps get you most of the way. The first tells you whether pinned data is present at all; the second looks for the field names that typically hold a pasted key.

shell

# is there pinned execution data?
jq 'has("pinData")' workflow.json

# which nodes have it, and how big
jq '.pinData | keys' workflow.json

# obvious inline secrets in node parameters
grep -Eio '"(authorization|api[-_]?key|token|secret|password)"[^,]*' workflow.json

If you drop the workflow into the Pixtex editor and create a share link, the same scan runs for you: pinned data is stripped before anything is hosted, and parameters that look like a bearer token, an sk_/ghp_-style key, a JWT or a PEM private key are flagged so you can decide. Nothing is auto-redacted — a silently mangled workflow that imports broken is worse than a warning you can act on.

The safest answer is usually a picture

Most of the time the person asking does not need your workflow, they need to see it. A rendered diagram carries the node types, the names, the connection topology and the branch structure — enough to debug a routing problem or review an architecture — and carries none of the parameters, none of the pinned data and none of the credential references.

That is the whole argument for posting an image on the community forum instead of a JSON blob, and it is why the forum answer you get back tends to be faster: the reader can see the shape immediately instead of importing a file to look at it.

When you do have to send the JSON

Strip pinData first — jq 'del(.pinData)' workflow.json.
Replace inline keys with a placeholder before sending, and rotate anything that has already been in a file you shared. A key that reached someone else's disk is a key you no longer control.
Send a subset. Selecting a few nodes on the n8n canvas and copying them produces valid workflow JSON for just that fragment — usually all a support thread needs.
Prefer a link that expires over an attachment that does not. A Pixtex share link lasts 24 hours; an email attachment lasts as long as the mailbox.

On the Pixtex side: workflow JSON never travels in a URL or a query string, is never written to a log, and a render is done in memory and discarded — hosted images store only the finished PNG. Connecting an n8n instance sends your instance API key in a POST body for that request alone; it is never persisted, in the browser or on the server.

How to share an n8n workflow safely