Escaping is easy to get wrong because several different jobs look similar from a distance. You have text, the text contains special characters, and another system needs to receive it without misunderstanding it. The mistake is assuming that one kind of escaping works everywhere.
URL encoding, HTML escaping, and JSON escaping solve different problems. A space in a query string is not the same problem as a < character in rendered HTML or a quotation mark inside a JSON string. The Case / Slug / Escape tool helps by keeping those outputs close together, but the useful part is knowing which output belongs to the destination you are preparing.
URL encoding is for URLs and query values
Use URL encoding when text is going into a URL component, especially a query parameter or a value that may contain spaces, punctuation, or non-path-safe characters.
Suppose a support link needs to include a search term such as pricing & billing. Pasting that phrase directly into a URL can change how the URL is interpreted because & already has meaning inside a query string. URL encoding turns the text into a form that can travel inside the URL without being confused for URL syntax.
This is different from creating a slug. A slug usually turns a title into a readable path segment such as pricing-and-billing. URL encoding preserves the original value more directly for transport.
HTML escaping is for text that will be rendered in HTML
Use HTML escaping when text needs to appear as text inside an HTML context, not become markup.
If a code example includes <button> and you want readers to see those characters, the browser needs the characters escaped. Otherwise it may interpret them as an actual element. HTML escaping is about preventing text from being read as HTML syntax in places where the content should remain visible text.
That matters in documentation, CMS fields, changelogs, and product copy. It is especially relevant when the source text includes examples of markup, snippets, or user-generated values that should not become part of the page structure.
JSON escaping is for string values inside JSON
Use JSON escaping when text needs to sit safely inside a JSON string.
A quotation mark is harmless in normal prose, but inside a JSON string it can close the string early. A newline can also need representation that keeps the JSON valid. JSON escaping is about preserving the value while keeping the surrounding JSON parseable.
This often appears when teams share API examples, config snippets, analytics payloads, or sample data. If the next step is broader structured-data cleanup, pair this article with How to Format JSON Before Sharing an API Example and the JSON / YAML / TOML Converter.
Choose the escaping based on the destination
The simplest rule is destination first.
| Destination | Use | Why |
|---|---|---|
| URL query value or URL component | URL encoding | Keeps text from being interpreted as URL syntax |
| Visible text inside HTML | HTML escaping | Keeps special characters from becoming markup |
| String value inside JSON | JSON escaping | Keeps quotes, slashes, and line breaks parseable |
| Public article or route title | Slug generation | Creates readable path text rather than preserving every character |
Converty helps because you can paste once and compare the outputs without opening a separate encoder for each case. That keeps the job proportional. You are not building a pipeline; you are preparing one text value for the place it needs to go.
Open the Case / Slug / Escape tool when you need to decide whether the next output should be a slug, a URL-encoded value, HTML-safe text, or a JSON-safe string.
