WordPress wp_kses_allowed_html Example: Customize Safe Markup Rules

Last reviewed: May 5, 2026

Many teams stop at wp_kses() and never revisit the allowlist itself. That leaves plugin code with either a too-broad markup policy or a copied array that nobody remembers how to evolve. wp_kses_allowed_html() is useful when code needs the baseline rules for a known context and wants to review or extend them deliberately.

This guide shows how to build a constrained custom allowlist from the WordPress baseline instead of inventing one from scratch or allowing far more HTML than the feature requires.

Start from a known allowlist context

<?php
$allowed = wp_kses_allowed_html( 'post' );
$allowed['mark'] = array();
$allowed['span'] = array(
	'class' => true,
);

$safe = wp_kses( $raw_html, $allowed );

This approach is usually easier to reason about than rebuilding the entire rule set by hand when the feature is mostly post-like but needs one or two deliberate adjustments.

Do not expand the allowlist more than the feature needs

If the UI only needs a highlighted inline marker and a single class-bearing wrapper, do not quietly inherit dozens of tags and attributes just because a broader context exists. Smaller allowlists are easier to audit and safer to revisit later.

Keep the chosen context explicit

Passing post, data, or another context is a real product decision. Future reviewers should be able to tell why that baseline was chosen and what changed from it.

Review the output side as well as the input side

Sanitization is only one part of the pipeline. The final HTML still needs the right output location, CSS expectations, and a feature design that does not encourage users to fight the allowlist with unsupported markup.

Common mistakes

• Using a very broad baseline for a tiny snippet. The feature usually needs less HTML than a post body.
• Copy-pasting a large allowlist without documenting why. Future reviewers lose the threat model.
• Adding permissive attributes casually. Attribute expansion is where risk often grows.
• Forgetting that output design should match the sanitized markup model. Unsupported markup creates editorial friction.

Production checklist

• Start from the narrowest sensible baseline context.
• Add only the tags and attributes the feature truly needs.
• Document why the chosen context and extensions exist.
• Keep sanitization and final output behavior aligned.
• Review allowlists again when plugin UI requirements change.

Related reading

Pair this with the wp_kses guide for the broader sanitization flow, and with the wp_editor article if the HTML originates from a rich text input surface.

References and further reading

• WordPress Code Reference: wp_kses_allowed_html()
• WordPress Code Reference: wp_kses()
• WordPress Code Reference: wp_kses_post()