ForHosting KIT · Data & Files

Sanitize HTML

Strip the dangerous parts out of HTML before you show it: in the example, a script, an embedded frame, a hidden click action and a link to script code all go, leaving only the paragraph Hola and the word click. Free in your browser.

  • Free
  • Runs in your browser
  • No sign-up
  • Your data stays on your device
Use it from WebAPIEmailTelegramApp soon

Anywhere users can submit rich text — comments, bios, support tickets, rendered emails — an attacker can try to slip a script tag past you.

Why an allowlist beats a list of banned tags

Anywhere people can submit rich text, such as comments, profile bios, support tickets or formatted emails, someone can try to slip a script past you. Sound cleaning works by allowlist rather than by a list of banned patterns: it defines which tags and attributes are safe and drops everything else, including anything a browser might reinterpret in an unexpected way. That matters because browsers are extremely tolerant of broken markup, and code that looks harmless in one place can run in another. Lists of banned tags have been bypassed that way for as long as rich-text input has existed on the web.

What comes out, and where to use it

In the example, a paragraph with a hidden click action, a script, a link pointing to script code and an embedded frame go in, and only the paragraph with Hola and the link text click come out. Harmless formatting such as bold text, links and line breaks is meant to survive. Use it on user bios in a community, on articles sent by outside contributors before they reach the live site, and in comment or ticket viewers that show one person's HTML to others. Clean on the way in, before storing, instead of hoping the page escapes it correctly later, and never rely only on checks in the sender's browser.

Allowlisting, not guessing

Sound sanitization works by allowlist, not denylist: rather than trying to enumerate every dangerous pattern, it defines which tags and attributes are safe and drops everything else, including anything a browser's error-tolerant parser might reinterpret in a way the sanitizer didn't expect.

This matters because HTML parsing is notoriously permissive — browsers will render malformed markup that looks harmless in one context and executes in another, which is exactly the kind of quirk that has produced real-world XSS bypasses against naive filters for as long as rich-text input has existed on the web.

User bio and profile fields

A community platform sanitizes HTML in user bios, allowing bold, links and line breaks while blocking any executable content.

CMS content from external contributors

A publisher sanitizes HTML submitted by freelance writers before it's rendered on the live site, closing off a common injection vector.

Will safe formatting like bold text and links survive?

Yes, standard formatting tags and safe attributes are preserved by default so legitimate rich text still renders correctly.

Is this better than a manual tag denylist?

Yes, it works by allowlisting known-safe tags and attributes instead of trying to enumerate every dangerous pattern, which is the approach that misses obscure vectors.

Is submitted HTML stored afterward?

No, both the submitted and sanitized HTML are deleted after the retention window and never used for training.

What happens to a link that runs a script?

The link text stays, but its dangerous address is removed. In the example, a link pointing to script code comes back as the plain word click with no destination, so nothing runs when someone presses it.

Is the content inside a removed script kept?

No. Dangerous elements such as scripts and embedded frames are dropped together with everything inside them, while ordinary text in safe tags stays. In the example, the alert inside the script disappears completely and only Hola and click remain.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/data/html-sanitize

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/data/html-sanitize \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"html":"<p onclick='\''x()'\''>Hola</p><script>evil()</script>"}'
{
  "html": "<p onclick='x()'>Hola</p><script>evil()</script>"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "data.html_sanitize",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

max_mb25
HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

This endpoint strips executable content and dangerous attributes while leaving the harmless formatting your users actually intended.

What happens on each request

Send POST /data/html-sanitize with the untrusted HTML, and you get a task_id back immediately while sanitization runs. The cleaned HTML — safe formatting tags preserved, scripts and dangerous attributes removed — arrives through a signed webhook call or waits behind a signed link valid for 24 hours.

How it fits an automated pipeline

Comment systems, support-ticket viewers, CMS content ingestion and any pipeline that renders user-authored HTML back to other users should sanitize on the way in, not hope the frontend framework escapes correctly on the way out. Because the task is billed per request with no charge on failure, it's cheap enough to run on every single submission rather than sampling or trusting client-side validation, and the async webhook flow means a comment form can accept input immediately and swap in the sanitized version once it's ready, without blocking the user on a synchronous scan.

Comment section moderation

A blog platform sanitizes every submitted comment before storing it, stripping any script or event-handler attribute a commenter tried to inject.

Rich-text support tickets

A helpdesk sanitizes HTML pasted into ticket replies so agents can safely view formatted messages without risking a stored XSS payload.

How do I sanitize HTML with the API?

POST the untrusted HTML to /data/html-sanitize, keep the returned task_id, and collect the cleaned HTML by webhook or a signed link valid for 24 hours.

Is the HTML sanitizer API free?

No, there is no free tier or trial; it costs $0.002 per request, and a failed request is never charged.

Does it remove all XSS vectors, including event handlers?

Yes, it strips script tags, javascript: links, event-handler attributes and other executable content, keeping only safe formatting tags and attributes.

Can I sanitize HTML in bulk?

Yes, submit one async task per document and collect each result by webhook, which suits batch imports of user-generated content.

Is this endpoint live?

Yes, data.html_sanitize is live and accepting requests now.

Read the full KIT documentation →