JSON Payloads: Files or Clips — Where Should They Live?

A JSON payload is a file, not a clipboard entry. Below 1 KB, pasting it into chat is fine. Above 1 KB, it starts to be a problem. Above 10 KB, it is reliably a problem. Above 100 KB, the clipboard may truncate it, the chat may refuse it, and any parser that receives it will fail in ways the sender did not anticipate. The clipboard is a transport for snippets, not a transport for documents, and JSON payloads above a certain size are documents.

This guide is about why JSON belongs in files, what breaks when it goes on the clipboard, and the practical patterns for moving JSON between tools. It is written for developers, SREs, and API testers who handle JSON payloads regularly. For neighbouring topics, see PowerShell here-strings and the clipboard, API keys on the clipboard are an incident, and clipboard habits that keep secrets off the stack.

What breaks when JSON goes on the clipboard

1. Win+V's 4 MB per-item cap

Windows clipboard history caps each item at 4 MB. A JSON payload above 4 MB is silently truncated when added to history. The truncated version is what gets re-copied if someone uses the history entry. For a 5 MB API response, the first megabyte is gone; the JSON no longer parses.

The 4 MB cap is documented in Microsoft's official Windows clipboard support page. It has been stable across Windows 10 and 11. There is no registry override; the cap is a design choice, not a configuration.

2. Chat and ticket truncation

Slack, Jira, GitHub issues, and most email clients truncate pasted content at varying thresholds. Slack's snippet upload limit is 1 MB for most workspaces; pasted text is truncated in the message input at a much smaller size. Jira's comment field truncates display at around 32 KB but accepts larger input. GitHub issue bodies accept up to 65,536 characters but render poorly above 10 KB. Email clients vary widely; Outlook's default message size limit is 10 MB for the entire message, including attachments.

The result of pasting a 200 KB JSON blob into chat is usually a truncated paste that the reader cannot parse, combined with a wall of text that disrupts the channel.

3. Line-ending corruption

When JSON is copied from a browser's network panel or a terminal and pasted into another tool, the line endings may be converted. Browsers typically use LF; PowerShell uses CRLF; macOS tools (pre-2019) used CR. A JSON parser in strict mode may reject \r inside strings, even though the JSON spec (RFC 8259) allows it.

4. Whitespace and formatting changes

Minified JSON (no whitespace) and pretty-printed JSON (with whitespace) parse to the same data, but they are different strings. Pasting minified JSON into a chat renders as a single 5,000-character line that is unreadable. Pasting pretty-printed JSON into a code formatter that re-minifies it produces a different string. Neither matters for parsing, but both matter for human review.

5. Token leakage

JSON payloads frequently contain tokens — Authorization headers in request captures, access_token fields in OAuth responses, api_key fields in service responses. Pasting a JSON payload into chat or a ticket without redacting these fields leaks the tokens. See API keys on the clipboard are an incident for the rotation discipline.

When JSON on the clipboard is fine

There is a narrow range where JSON on the clipboard is the right choice:

• Small payloads under 1 KB. A 200-byte error response, a 500-byte config snippet, a 800-byte webhook payload. These fit in chat without truncation and parse cleanly when re-copied.
• Short-lived working copies. A payload being moved from one tool to another in the same minute, with no chat or ticket involvement. The clipboard is a transport, not a store.
• Pretty-printed excerpts. A 20-line excerpt from a larger payload, with the relevant fields highlighted. The excerpt is content, not a payload; it does not need to parse.

For these cases, the clipboard is appropriate. For anything larger, the file is the right medium.

The file-first pattern

The pattern for handling JSON payloads above 1 KB:

1. Save the payload to a file. From a browser DevTools network panel, "Copy as fetch" or "Save all as HAR". From a terminal, redirect output: curl ... > response.json. From a test runner, write the response body to a fixture file.
2. Share the file path or the file. For colleagues on the same machine, the file path is enough. For colleagues elsewhere, upload the file (Slack snippet, Google Drive, S3 presigned URL).
3. Parse the file with jq or ConvertFrom-Json. Never paste a large JSON blob into a parser; let the parser read the file.

Example workflow for inspecting a large API response:

curl -s https://api.example.com/endpoint > response.json
jq '.data[] | select(.status == "active")' response.json

The file is the source of truth; jq reads from the file; the clipboard is not involved. If a colleague needs the same data, share the file or the path.

jq for JSON on the clipboard

For the small case where JSON is already on the clipboard and needs to be inspected, jq can read from the clipboard via a small wrapper:

# bash/WSL: pretty-print the clipboard contents as JSON
pbpaste | jq .

(pbpaste is the WSL wrapper from WSL and Windows clipboard: what crosses the boundary.)

# PowerShell: pretty-print the clipboard contents as JSON
Get-Clipboard | ConvertFrom-Json | ConvertTo-Json -Depth 10 | Set-Clipboard

This is useful for reformatting minified JSON copied from a browser. The pattern fails for payloads above 4 MB (Win+V truncation) or above the chat paste limit (truncation in the source).

File-sharing options

For sharing a JSON file with colleagues, the options by sensitivity:

The clipboard is appropriate for none of these categories above 1 KB. The clipboard is a transport for snippets, not a sharing mechanism for documents.

Redacting JSON before sharing

Before sharing any JSON payload, scan for and redact:

• Authorization headers (Bearer ..., Basic ...)
• access_token, refresh_token, id_token fields
• api_key, apikey, api-key fields
• password, secret, client_secret fields
• Connection strings inside database_url or connection_string fields
• PII fields (email, phone, government IDs) if the payload is going outside the team

A jq filter is the cleanest way to redact:

jq 'walk(if type == "object" and has("authorization") then .authorization = "<redacted>" else . end)' response.json

For deeper coverage of redaction patterns, see stack traces, tokens, and the clipboard.

A worked example

A developer is debugging a failed API call. The response is a 350 KB JSON payload with nested data, an error object, and a request ID. The developer needs to share this with a colleague.

Wrong: copy the entire response body from DevTools, paste into Slack. Slack truncates the paste at ~32 KB; the error object is in the truncated portion; the colleague cannot see the failure. The developer sends a follow-up with a screenshot of the error object, which is also truncated because Slack's image preview crops long text.

Right: save the response body to a file (response.json), upload the file to Slack as a snippet, share the snippet link in the channel. The colleague opens the snippet, runs jq '.error' response.json locally, sees the error, and responds with a fix in five minutes.

The file-first pattern takes the same amount of time as the paste, produces a shareable artifact, and avoids the truncation problem entirely. The discipline is in knowing when to switch from paste to file.

The threshold, restated

The rule of thumb: if the JSON is under 1 KB and does not contain secrets, paste is fine. If the JSON is between 1 KB and 10 KB, paste works in most chat tools but is borderline. If the JSON is above 10 KB, switch to a file. If the JSON contains secrets of any kind, do not paste it; redact first, then save to a file.

The thresholds are not arbitrary. They come from the practical limits of common tools: Win+V's 4 MB cap, Slack's 1 MB snippet limit (with smaller paste limits in the message input), GitHub's 65 KB issue body cap, and the cognitive load on the reader of scrolling through a wall of text. A 200 KB JSON blob pasted into chat is not just technically problematic; it is also inconsiderate to the reader, who has to scroll past it to find the next message. The file-first pattern is a courtesy as well as a technical discipline.

Background for this constraint is Copying From Windows Terminal Without Garbled Codes.

Related reading

• API Keys on the Clipboard Are an Incident
• How to Copy a File Path That Works in the Terminal
• Best Clipboard Habits for Developers in 2026
• Clipboard Tools on Multi-Monitor Windows Setups

Sources

• Microsoft Support — Using the clipboard on Windows — official statement of the 4 MB per-item cap and the 25-item history limit
• IETF — RFC 8259: The JSON Data Interchange Syntax — the JSON specification, including the handling of whitespace and control characters
• jq — GitHub README — official documentation for jq, the standard command-line JSON processor
• Chrome DevTools — Network panel reference — official documentation for Chrome DevTools' network panel, including "Save all as HAR" and "Copy as fetch"
• Slack — File upload limits — Slack's official guidance on file size limits and snippet uploads, which are the right alternative to pasting large JSON

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support