New: Share Tool State via URL and Upload/Download Files

New: Share Tool State via URL and Upload/Download Files

We just shipped two features that make ToolBox tools dramatically more useful in real developer workflows: shareable URLs and file upload/download. This post explains what they are, how they work under the hood, and how to integrate them into your day-to-day work.

The Problem These Features Solve

Developer tools are most useful when they fit into existing workflows rather than requiring you to work around them.

Before these features, ToolBox tools were isolated islands. You could format JSON, test a regex, or decode a JWT --- but sharing the result required copying text into Slack or email, where formatting often broke. Working with large files meant copy-pasting hundreds or thousands of lines into a textarea, which was slow and introduced copy-paste errors with special characters.

Two features change this fundamentally:

1. Shareable URLs let you encode any tool's current state into a link. Your teammate opens the link and sees exactly what you were looking at, with the same inputs and settings, ready to use.

1. File upload/download lets you work with files directly, rather than treating every tool interaction as a copy-paste exercise.

Together, these make ToolBox tools useful in team workflows, not just individual debugging sessions.

Share Any Tool State via URL

Ten tools now support shareable URLs. When you click the Share button in any supported tool, ToolBox encodes your current input and settings into the URL hash fragment and copies the resulting URL to your clipboard. Anyone who opens that link lands in the tool with the exact same state.

Supported Tools for URL Sharing

How URL State Sharing Works: Technical Details

When you click Share, the tool serializes its current state to a JavaScript object. For the Regex Tester, this might look like:

{
  pattern: "\\d{3}-\\d{3}-\\d{4}",
  flags: "gi",
  testString: "Call 555-123-4567 or 800-555-9876 for support"
}

This object goes through three steps:

1. JSON.stringify() produces a JSON string
2. LZ-based compression reduces the length for large payloads (important for the Diff Checker, which can have two substantial blocks of text)
3. Base64URL encoding produces a URL-safe string (replacing + with - and / with _ so the string can appear in a URL without percent-encoding)

The result is appended to the URL as the hash fragment:

https://toolbox-kit.com/tools/regex-tester#eyJwYXR0ZXJuIjoiXFxkezN9LVxcZHs...

On the receiving end, when someone opens the URL, the tool reads window.location.hash, reverses the process (Base64URL-decode, decompress, JSON.parse), and populates its state from the result. This happens synchronously on mount, so the content appears immediately --- no loading state, no async fetch.

The encoded state is capped at 8KB. This is a practical limit for URL length compatibility across browsers, link shorteners, email clients, and Slack. It covers the vast majority of real-world use cases. For content larger than 8KB, use the download feature instead.

Why the Hash Fragment?

The hash fragment --- the part of the URL after # --- has a crucial property: it is never sent to the server. When your browser requests https://toolbox-kit.com/tools/regex-tester#data, the server receives a request for /tools/regex-tester only. The #data part stays entirely in the browser.

This means the shared state is never transmitted to any ToolBox server. The data flows directly from the sharer's browser URL to the recipient's browser URL, with no server acting as an intermediary. A JWT you share as a link stays between you and whoever you send the link to.

This is different from tools that store shared content in a database and give you an ID. With those tools, your data lives on their servers. With ToolBox URL sharing, your data lives in the URL.

The hash also has practical advantages:

• It is preserved when you bookmark a URL
• It is included when you copy the address bar
• Changes to the hash fragment do not trigger a page reload or server request
• It works correctly with browser back/forward navigation

Practical Use Cases for URL Sharing

Code review and pull request discussion. You are reviewing a PR that introduces a new regex for input validation. Open the Regex Tester, paste the pattern and a set of representative test strings, verify the behavior (including edge cases), and include the shareable link in your PR review comment. Your comment is self-documenting and your teammates can interactively verify the behavior themselves.

Debugging API responses. Your backend returns an unexpected JSON structure. Paste it into the JSON Formatter, format it, and share the link in the bug report ticket. The person investigating can see the full structure immediately, without needing to reproduce the API call.

JWT inspection during incident response. Something is wrong with authentication in production. You have a JWT from the logs. Decode it in the JWT Decoder, verify the claims and expiration, and share the link with your on-call colleagues. Everyone is looking at exactly the same decoded token --- no "can you paste me that JWT?" back-and-forth.

Diff sharing in postmortems. After a production incident involving a configuration change, show the exact diff between the previous and current config in the Diff Checker. Share the link in the postmortem doc. The diff is preserved exactly as you saw it.

Color communication with designers. Instead of saying "I think the button should be somewhere around that blue we used before," open the Color Converter, enter the exact hex value, and share the link. The color is specified precisely in every format: hex, RGB, HSL, and HSB.

Regex documentation. You wrote a complex regex for email validation or phone number formatting. Instead of documenting it with a comment like "matches US phone numbers," create a shareable Regex Tester link with the pattern and a variety of test strings showing matches and non-matches. Reference this link in your code comments, wiki, or README. When the regex needs to change, you have a ready-made test harness.

Hash verification. You generated a hash of a file or string using the Hash Generator and want to document the input for verification purposes. Share the link so anyone can regenerate and verify the hash.

Training and onboarding. Teaching a colleague about JWT structure or URL encoding? Share a link to the relevant tool pre-loaded with an example. The learner can interact with the tool directly, not just read a static explanation.

Upload and Download Files

Eight tools now have Upload and Download buttons for direct file interaction.

Upload

The Upload button opens a file picker. Select a file from your disk and ToolBox reads it directly into the input textarea. The file is read by the browser's File API and the content is placed in memory as a string. No upload occurs.

Upload accepts files of any size the browser can handle (practical limit: a few hundred megabytes before browser memory becomes a concern, though most text-based files are well under 10MB). There is no server-side size limit because there is no server involved.

Download

The Download button saves the tool's current output to a file. The browser creates a Blob from the output text and triggers a download using a temporary Object URL. The file is saved directly to your downloads folder.

Supported Tools for File I/O

Why File I/O Matters More Than You Might Think

Copy-pasting large files is error-prone in ways that are easy to overlook.

Many text editors add or strip trailing newlines when you copy. Some add BOM (byte order mark) characters. Some translate line endings (CRLF on Windows vs LF on Unix). Some truncate clipboard content above a certain size. Special characters can get mangled depending on the editor and clipboard encoding.

Loading a file directly via the File API gives you the raw bytes the file contains, decoded as text using the specified encoding (UTF-8 by default). This eliminates the copy-paste layer entirely and ensures you are working with the actual file content.

The same principle applies to downloading: instead of selecting all, copying, opening a text editor, pasting, and saving --- which introduces all the same encoding risks --- the Download button writes the exact bytes you want to disk.

Workflow Examples: File I/O in Practice

Formatting a large JSON configuration file:

Without file upload, this workflow is: open JSON file in editor, select all (potentially several thousand lines), copy, switch to browser, paste into JSON Formatter, format, select all, copy, switch back to editor, select all, paste.

With file upload: click Upload, select the file, format, click Download. Three clicks.

Converting a Kubernetes deployment YAML to JSON:

Kubernetes YAML files can be complex multi-document files with several hundred lines. Uploading to the YAML/JSON Converter and downloading the JSON output is significantly faster than the copy-paste alternative.

Diffing configuration files between environments:

# Typical workflow without file upload:
# 1. Open config.prod.json in editor
# 2. Select all, copy
# 3. Paste into left pane of Diff Checker
# 4. Open config.staging.json in editor
# 5. Select all, copy
# 6. Paste into right pane
# 7. Wait for diff to render

# Workflow with file upload:
# 1. Click Upload on left pane, select config.prod.json
# 2. Click Upload on right pane, select config.staging.json
# 3. Diff renders

For 500-line JSON files, the file upload workflow is much faster and eliminates copy-paste encoding issues.

Processing CSV exports:

Business analysts frequently export data from databases or spreadsheets as CSV and need to convert it to JSON for further processing. The CSV to JSON tool with upload support lets you drop a CSV file in and download JSON output immediately.

Code formatting during batch cleanup:

You have a directory of JavaScript files that need formatting. While the Code Formatter cannot process an entire directory at once (that is a job for Prettier on the command line), it can format individual files you upload and let you download the formatted result.

How File Processing Works: Under the Hood

All file reading and writing uses browser-native APIs. Here is the technical flow for Upload:

// When user selects a file
async function handleFileUpload(file) {
  // Read the file content as text
  const text = await file.text(); // Browser File API, no server involved

  // Populate the textarea
  setInputValue(text);
}

And for Download:

// When user clicks Download
function handleDownload(content, filename) {
  // Create a Blob from the output text
  const blob = new Blob([content], { type: "text/plain;charset=utf-8" });

  // Create a temporary download URL
  const url = URL.createObjectURL(blob);

  // Trigger download
  const link = document.createElement("a");
  link.href = url;
  link.download = filename;
  link.click();

  // Clean up the object URL
  URL.revokeObjectURL(url);
}

No fetch(), no XMLHttpRequest, no server endpoint. The file content goes into a JavaScript string in browser memory, processed by the tool's existing JavaScript code, and written back to disk via Blob. The ToolBox server never sees the file content.

This implementation pattern means ToolBox can process any file you are willing to open in a browser tab, regardless of how sensitive the content is.

Privacy: Why Client-Side Matters

Both features --- URL sharing and file I/O --- are designed with client-side-only processing as a non-negotiable constraint. This is not a marketing claim; it is verifiable by inspecting network traffic.

Open your browser's DevTools Network tab before uploading a file or clicking Share. You will see no outbound request carrying your file content or URL-encoded state. The data stays in your browser.

This matters in concrete situations:

• You are debugging an authentication issue and need to decode a JWT from your production environment. Pasting a production JWT into a tool that uploads it to a server means a token that grants access to your system is now on someone else's server's logs. With ToolBox, the JWT is decoded in your browser and never leaves.

• You are formatting a JSON file containing user PII for a GDPR-related debugging session. Uploading that to a server creates a data handling obligation. Processing it locally does not.

• You are reviewing configuration files for a client's system under NDA. The content of those files belongs to the client, and using server-side tools may violate your agreement. Browser-side processing does not.

• Your company's security policy prohibits uploading code or configuration to third-party services. ToolBox's client-side processing means these tools are policy-compliant in most organizations with such restrictions.

Combining URL Sharing and File I/O

The two features are complementary and can be used together.

One workflow: process a file, then share a representative excerpt. Upload a large JSON file to the JSON Formatter. The file formats. Trim the output to the relevant section in the textarea. Click Share. Now you have a link to that specific section of the formatted JSON, not the entire file (which might exceed the 8KB URL limit).

Another workflow: receive a shared link, download the content. A colleague shares a Diff Checker link with a configuration comparison. You want to save it. Open the link, and from each pane, copy and save the content.

A third workflow specific to the Diff Checker: upload both files, verify the diff is what you expected, then share the link (if it fits in 8KB) or screenshot the diff for documentation.

Tools That Benefit Most from File I/O

Not all tools benefit equally from file upload. Here is the actual impact by category:

High impact: Tools that work with structured data files. JSON Formatter, XML Formatter, YAML/JSON Converter, CSV to JSON, JSON to CSV. These tools exist to process files, and the upload/download workflow is dramatically faster than copy-paste for any file over a few hundred lines.

Medium impact: Diff Checker. Diffing is inherently a file-comparison operation, so being able to load files directly is natural. For small text snippets, copy-paste is fine. For config files or source files, file upload is much better.

Lower but still valuable: Code Formatter. Most code lives in files, so being able to upload and download is useful. However, most developers format code via editor plugins or build tools, so this is more of a convenience than a workflow change.

What Is Coming Next

We are continuing to expand these features to more tools. Upcoming additions:

Shareable URLs will be added to the SQL Formatter, Markdown Preview, and the CSS Minifier. The SQL Formatter in particular is well-suited for sharing --- "here is the query I am trying to optimize" is a common communication need.

File I/O will be added to the CSV to JSON (upload CSV, download JSON), Markdown Preview (upload markdown, download rendered HTML), and the SQL Formatter (upload a .sql file, download formatted .sql).

We are also evaluating persistent shares --- short links that store state server-side with explicit user consent and expiration --- for cases where the 8KB URL limit is constraining. This would be opt-in and would be clear about the server-side storage involved.

Making ToolBox Part of Your Workflow

The best developer tool is one you reach for without thinking, use in seconds, and move on. These two features move ToolBox closer to that goal.

If you use the same tool regularly for the same type of data, the file I/O workflow compounds. Instead of a 90-second copy-paste ritual, you have a 10-second upload-format-download workflow. Over dozens of uses per week, that adds up.

If you work in a team and frequently need to share specific inputs with colleagues --- API responses, regex patterns, configuration diffs, color values --- URL sharing eliminates a whole category of "can you paste me that thing" back-and-forth.

If there is a tool you want shareable URLs or file I/O for, let us know via the request page. Every feature in ToolBox reflects something a developer actually needed in their workflow, and we want to know what is still missing from yours.

Comparison: URL Sharing vs. Other Sharing Approaches

URL sharing is not a new concept. Dozens of tools offer some form of it. Here is how the approaches compare:

URL Hash Sharing (ToolBox approach)

The state is encoded in the URL hash fragment. No server is involved. No account required. Works instantly for any recipient.

Advantages:

• Zero server-side storage
• No account or login required for the sharer or recipient
• Works offline for the recipient once the URL is loaded
• Data cannot be accidentally exposed in server logs

Disadvantages:

• Limited to roughly 8KB of encoded state
• Very long URLs (though still functional for sharing in any context that supports URLs)
• State is ephemeral --- if the URL is lost, the state is lost

Server-Stored Shares (Pastebin, GitHub Gist, Carbon, etc.)

Content is uploaded to a server, stored, and given a short ID. The recipient retrieves the content from the server using the ID.

Advantages:

• Short, clean URLs
• No size limit beyond the service's storage limits
• Content persists as long as the service stores it

Disadvantages:

• Content lives on the provider's servers (privacy and data handling implications)
• Requires account for some features
• Dependent on service availability
• Content may expire or be deleted
• Server logs may retain the content

Gists for Code Sharing

GitHub Gist is excellent for sharing code snippets with syntax highlighting, versioning, and comments. If you are sharing code to discuss with a colleague, Gist is a better choice than ToolBox URL sharing.

ToolBox URL sharing is not trying to replace Gist. It is optimized for a different use case: sharing the state of a specific transformation, validation, or conversion. "Here is the regex I am using and the strings I am testing it against" is ToolBox. "Here is the utility function I wrote" is Gist.

The two are complementary. Link a ToolBox Regex Tester share in a Gist comment to show what the regex in the code is testing.

Real-Time Collaboration Tools

Tools like CodeSandbox or StackBlitz offer real-time collaborative editing. ToolBox is not this. URL sharing is asynchronous --- you share a state snapshot, not a live session.

For the use cases ToolBox is designed for (quick transformations, validation, inspection), real-time collaboration would be overkill. The goal is "show someone what I am seeing" not "edit this together."

Integrating Shareable URLs into Team Workflows

In Git and Pull Request Comments

GitHub, GitLab, and Bitbucket all support markdown in pull request descriptions and comments. Shareable tool links work naturally here.

## Changes

This PR updates the email validation regex.

**Before**: `/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/`

**After**: `/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/`

[Test cases for the new regex on ToolBox →](https://toolbox-kit.com/tools/regex-tester#eyJwYXR0ZXJuIjoi...)

The new regex handles 4-character TLDs like .info and .name.

In Slack and Team Chat

Slack, Discord, and Teams all render URL previews for links. A shareable ToolBox link can be pasted directly into a channel to show "here is the diff" or "here is the JWT I decoded."

Shareable tool links are more useful than pasting the raw JSON or regex into chat, where:

• Formatting is lost
• The tool context is lost
• The recipient has to copy-paste it somewhere else to work with it

In Documentation and Wikis

Internal wikis, Notion documents, and Confluence pages benefit from shareable tool links as living examples. Instead of a static code block showing an example regex, link to a Regex Tester showing the pattern with real test cases.

Example in a Confluence page documenting your API:

## Authentication

All API endpoints require a Bearer token in the Authorization header.

Token format: [See example decoded JWT on ToolBox →](...)

Token expiration: 24 hours from issuance. Verify the `exp` claim using the JWT Decoder.

In Bug Reports and Tickets

When filing a bug report about an unexpected API response or malformed data, including a formatted and shareable view of the data is more useful than pasting raw JSON or a screenshot.

A Jira ticket with a link to the JSON Formatter showing the unexpected payload is self-contained. Anyone who opens the link can inspect the full structure, not just the portion visible in a screenshot.

File I/O Compared to Command-Line Alternatives

ToolBox file upload is not trying to replace command-line tools for batch processing. For processing hundreds of files, scripting with jq, xmllint, yq, or prettier --write is the right approach.

File upload shines for individual file workflows where:

• You are not on a machine with your preferred CLI tools installed
• You are working in a restricted environment (corporate machine with limited software installs)
• You need to process one file right now without setting up a pipeline
• You want to visually verify the output before saving

Comparison for a single JSON file formatting task

For a one-off task on a machine without your dev environment set up, ToolBox upload/download is the fastest path.

Comparison for XML formatting

For YAML to JSON conversion

# Command-line approach (requires yq)
yq eval -o=json deployment.yaml > deployment.json

# Or with python (usually available)
python3 -c "
import yaml, json, sys
with open('deployment.yaml') as f:
    data = yaml.safe_load(f)
with open('deployment.json', 'w') as f:
    json.dump(data, f, indent=2)
"

Versus: upload to YAML/JSON Converter, click download. Both approaches are valid; the right one depends on your environment and whether you need the conversion in a script.

The Privacy Angle: Why It Matters for File Processing

When you upload a file to a server-based tool, you are trusting that server with your file content. For many types of developer files, this is a meaningful trust decision:

• Configuration files often contain database connection strings, API keys, internal hostnames, and security settings
• JSON API responses may contain PII, internal IDs, and business-sensitive data
• Log files contain system internals, error details, and sometimes user data
• JWT tokens grant authenticated access to your systems
• SQL files contain your schema, business logic, and potentially data

Most online developer tools process files on their servers. This is often fine for public data, but for anything sensitive, server-side processing creates risk: the content appears in server logs, may be cached, may be accessible to employees of the tool provider, and is subject to the tool provider's data retention policies.

ToolBox's client-side processing model eliminates this risk for the tools it covers. The file content never leaves your browser tab. There is no server to log it, cache it, or store it.

This is verifiable: open DevTools Network tab, upload a file, observe that no outbound request carries your file content. The trust model is different from server-based tools, and for sensitive developer files, this matters.

Frequently Asked Questions

Q: Is the shared URL permanent?

The URL contains the state directly in the hash fragment. It has no expiration. As long as the URL exists and ToolBox is available, the link will work. However, if ToolBox's URL structure changes (rare, but possible), old links may break. For long-term storage of important content, save a local copy as well.

Q: Can I edit shared content after opening a link?

Yes. When you open a shared link, the tool is fully functional. You can edit the input, change settings, and re-share with a new URL. The original shared URL does not change.

Q: What happens if the content is too large for the URL?

The Share button will show an error if the encoded state exceeds 8KB. For large content, use the Download button instead, save the file locally, and share the file through other means (email, cloud storage, Git).

Q: Is the file upload size limited?

There is no server-imposed limit because no server is involved. Practical limits are determined by your browser's available memory. For text-based files (JSON, XML, YAML, SQL), files up to several hundred megabytes will generally work. For most developer use cases, files are well under 10MB.

Q: Does file upload work offline?

Yes. Since file upload uses the browser's File API and does not make network requests, it works completely offline once the page is loaded. If you are working in an environment with restricted internet access, the tool still functions.

Q: Are downloads named correctly?

Yes. Downloads use a filename that reflects the tool and content type. For example, downloading from the JSON Formatter produces formatted.json. Downloading from the YAML/JSON Converter produces either output.json or output.yaml depending on conversion direction.

Tips for Getting the Most out of Shareable URLs

Test the link before sharing. Open the shared URL in a private/incognito window to verify it loads correctly and contains what you expect. This is especially important the first few times to build confidence in the feature.

Combine with link shorteners for cleaner communication. The raw ToolBox shareable URL can be long (though fully functional). If you are posting in a context where a shorter URL looks better, paste the ToolBox URL into a link shortener like Bitly or your company's internal URL shortener. The final URL resolves to the full ToolBox URL, which works correctly.

Include context with the link. A bare URL in a Slack message is less useful than a sentence describing what it shows. "Here is the regex with test cases: [link]" is more immediately useful than just the link. The recipient knows what they are about to see.

Use URL sharing to create examples for documentation. Any time you explain a concept that could be illustrated with a tool, link to a shareable tool state rather than a static code block. The interactive version is more useful for the reader.

For the Diff Checker, upload both files before sharing. The shareable URL for the Diff Checker encodes both input panes. If you load files via upload, the content is in the textarea and will be included in the share. Confirm both panes have content before clicking Share.

Bookmarks work as personal saved states. You can bookmark a shareable URL to save a specific tool state for yourself. For example, bookmark a Regex Tester URL with your commonly used patterns and test strings as a personal reference. The state will still be there when you open the bookmark.

What These Features Say About How We Build ToolBox

The decision to implement URL sharing with hash fragments (rather than server-stored shares) and file I/O with browser APIs (rather than server-side processing) reflects a core design principle: keep user data in the user's control.

This is a harder path technically. Hash-based sharing requires more client-side engineering than a simple POST /share endpoint that stores content in a database and returns an ID. Browser-based file processing requires understanding the File API, Blob API, and memory management in browser contexts. Server-side approaches would have been faster to implement.

We chose the harder path because the privacy model is better, and because we think it matters. Developer tools often handle sensitive data --- production tokens, customer data, internal configurations, proprietary code. The default should be that this data stays with the developer, not that it passes through someone else's server unless there is a specific reason it needs to.

Every ToolBox tool is built with this constraint: run in the browser, process locally, do not send user data to servers unless the specific tool requires it (and even then, only with explicit user knowledge, such as the BYOK API tools where you supply your own key and know your data goes to OpenAI or Anthropic).

URL sharing and file I/O are the same principle applied to data portability: your tool state, your files, your data. Shareable if you choose to share it. Private if you choose to keep it private. No server required.

The tools you use every day shape how you think about problems. Tools that require server uploads normalize uploading sensitive data. Tools that work locally normalize keeping data local. We want ToolBox to reinforce good data hygiene habits by making the private, local workflow as fast and frictionless as possible.

These two features are a step in that direction. More tools will support them. The principle will not change.

If you have feedback on how URL sharing or file I/O could work better for your specific workflow --- different file format support, larger URL limits, additional tools --- reach out via the request page. ToolBox is built around real developer workflows, and your input directly shapes what gets built next.

The Diff Checker, JSON Formatter, Regex Tester, JWT Decoder, and Base64 Encoder/Decoder are all good starting points for both features. Open any of them, load some content, click Share, and see how the URL encodes your tool state. Then send it to a colleague and watch the friction disappear from a workflow that used to require copy-pasting.

---

Try URL sharing now with the Diff Checker or Regex Tester. Try file upload with the JSON Formatter or YAML/JSON Converter. Everything runs in your browser --- no account, no server upload, instantly ready.

---

Try URL sharing now with the Diff Checker or Regex Tester. Try file upload with the JSON Formatter or YAML/JSON Converter. Everything runs in your browser --- no account, no server upload, instantly ready.