HTML escape

HTML escape converts five characters that have special meaning in HTML into entity references. Ampersand becomes &, less-than becomes <, greater-than becomes >, a double quote becomes ", and a single quote becomes '. The result is plain text that can be placed in an HTML source context when the goal is to display those characters literally. A browser reading <strong> from source displays the tag text rather than treating it as a strong element.

The converter works on every matching occurrence and processes ampersands first. That order ensures each ampersand already present in the input is escaped before later replacements add new entity syntax. The output therefore represents exactly one escaping pass over the source. It does not parse a document, inspect whether a character is already part of an entity, or preserve selected tags. The source remains in the input area and the escaped copy appears in the result panel, ready for review and copying.

Enter <button aria-label="Save & close">Save</button> and the result replaces the brackets, ampersand, and quotation marks. When that escaped string is inserted as text in an HTML page, readers see the complete button markup rather than a live button. This is useful for tutorials, API documentation, support answers, and design-system notes. The entity references belong in the HTML source. A rendered preview normally shows the original symbols because the browser decodes the entities while displaying text.

For a shorter example, the statement 5 < 8 && 9 > 3 becomes 5 &lt; 8 &amp;&amp; 9 &gt; 3. Both ampersands are converted independently. A quoted value such as Sam's "draft" becomes Sam&#039;s &quot;draft&quot;. These outputs are intentionally verbose because entity syntax separates literal characters from HTML delimiters. If you paste the escaped output into a plain-text document rather than HTML source, the entity strings remain visible. Choose the destination before deciding whether escaping is needed.

Escaping is context-sensitive. This tool produces a general HTML text representation for the five common reserved characters, but software must still place untrusted content through the correct encoder at the point where it enters a document. Text inside an element, a quoted attribute, an unquoted attribute, a URL, CSS, and JavaScript each have different parsing rules. A string escaped for visible element text should not be assumed safe inside a script block or style block. Application frameworks often provide context-aware output escaping and should remain the primary control.

Do not use the tool as a replacement for a templating engine's automatic escaping, a Content Security Policy, input validation, or HTML sanitization. Escaping changes characters so markup is displayed literally. Sanitization parses HTML and removes or modifies disallowed elements and attributes while retaining permitted markup. Those are different goals. If users are allowed to submit a limited set of formatting tags, escaping everything removes the formatting, while inserting raw input risks interpretation. Use a maintained sanitizer configured for the intended markup policy in that situation.

Running already escaped text through the tool adds another layer. For example, &lt; contains an ampersand, so another pass returns &amp;lt;. A browser decodes that once and displays &lt; rather than the less-than symbol. This behavior is not an error in the converter; it follows the rule that every ampersand in the input is replaced. Double encoding commonly appears when content is escaped manually and then passed through a framework that escapes output again. Track which layer owns encoding and apply it exactly once for that output context.

When a page shows entity names instead of punctuation, inspect the stored value and the final HTML source. If storage already contains &amp;lt; and the template escapes it again, the browser may receive another ampersand layer. If storage contains a raw less-than character and the browser creates an element, escaping was skipped or bypassed. Work from the final parsing context backward. Avoid blindly decoding database values, because a value may be intentionally stored in its source form and protected correctly only during rendering.

The transformation runs in the browser with a fixed sequence of string replacements. It does not upload the text to a PWRKIT processing server. No network lookup is needed to map the five characters, and there is no server-side rendering step for the result. The workbench holds the input and output in page state. Reset clears both values in that state. Copying places the escaped result on the system clipboard, which can be read by software that has clipboard permission or by a clipboard-history feature configured on the device.

Local processing is convenient for code samples and ordinary text, but the tool is not a secret-management system. Source code may contain API keys, internal hostnames, customer information, or comments that should not be pasted into a general browser session. Remove sensitive values or use an approved development environment when policy requires it. The page does not save revisions, compare two escaping passes, or create a downloadable artifact. Keep the original in your editor so you can recover from an accidental reset or verify that the copied result came from the intended version.

Only five characters are replaced. The tool does not convert every non-ASCII character to a named or numeric entity, and that is normally unnecessary in a UTF-8 HTML document. Accented letters, emoji, line breaks, tabs, and other Unicode characters remain as entered. It does not normalize Unicode, change line endings, add a character-set declaration, or validate whether the surrounding document is well formed. If a legacy system requires ASCII-only numeric entities, this output does not meet that special requirement without another documented conversion step.

The result is not a security certificate. It cannot examine the code that later concatenates the value, detect a dangerous DOM sink, or know whether a developer will decode the text before insertion. It does not protect a value placed directly into JavaScript, CSS, an HTTP header, SQL, a shell command, or a URL parameter. Each of those destinations needs its own handling. Even within HTML, unquoted attributes and unusual parsing contexts can create risk. Prefer APIs that assign text content rather than building HTML strings whenever an application only needs visible text.

If the result still creates markup, first verify where it was pasted. In an HTML file, escaped entities should appear in source and decode to literal bracket characters on screen. In a browser developer console, a DOM API such as innerHTML may parse a string differently from textContent. In a framework, a raw-HTML escape hatch can bypass normal text rendering. Check the actual DOM and page source rather than assuming the copied string controls every later step. The converter cannot protect text after another component deliberately interprets or decodes it.

If readers see &lt; or &amp; in the finished page, count the encoding layers. Start with a minimal input such as <b> and follow it through storage, serialization, template rendering, and browser display. The correct layer should encode raw content once for its final context. If quotation marks appear unchanged, make sure the result panel was copied rather than the source field. When the copy action is blocked, select the result manually. Preserve a small test case that includes all five mapped characters to catch regressions in the consuming application.

Before using the output, identify the exact destination: visible element text, a quoted attribute, a documentation code sample, or another format. Confirm that the receiving layer does not escape the same value again and does not decode it before an unsafe insertion. Compare the rendered page with the source you intended readers to see. For code samples, check indentation and line breaks because this converter changes reserved characters but leaves whitespace alone. For application data, add automated tests around the real renderer rather than treating a manual conversion as permanent protection.

URL encode is for a query value or path component and follows percent-encoding rules, not HTML entity rules. Markdown preview renders Markdown and sanitizes the produced HTML; it does not expose this tool's escaped source as a live example. Case converter changes letter casing without making markup safe. If you need to remove allowed and disallowed HTML selectively, choose a sanitizer maintained for that purpose. HTML escape is the right tool when the task is narrow and explicit: represent reserved HTML characters as literal text in an HTML-aware destination.

Create a small fixture containing all five converted characters, ordinary Unicode text, a line break, and text that already contains an entity. Send that fixture through the same storage and rendering path as production content. Check both the delivered HTML source and the visible browser result. This catches missing escaping, double encoding, accidental decoding, and character-set problems at the layer where they occur. A screenshot alone cannot show whether literal text was produced through safe output handling or through markup that happened to look harmless.

Automated application tests should assert the DOM outcome, not merely repeat this converter's string replacements. For visible code, confirm that no executable element was created and that the text content equals the intended source. For attributes, use the framework or DOM API intended for attribute assignment and verify the resulting property. Keep the manual tool for inspection and example preparation, while placing lasting security guarantees in the application code, its tests, and the browser policies applied to the finished page.