WordPress wp_unslash Example: Normalize Request Input Safely

Last reviewed: May 6, 2026

One of the easiest ways to get WordPress input handling wrong is to sanitize slashed data directly from a superglobal. Core still expects request data to be unslashed before it reaches many sanitization helpers and APIs. wp_unslash() is the focused utility for removing those added slashes in a WordPress-aware way.

This guide shows where wp_unslash() belongs in the request pipeline and why the usual safe order is unslash first, sanitize second, validate third.

Unslash request data before sanitizing it

<?php
$note = isset( $_POST['vulnwp_status_note'] )
	? sanitize_textarea_field( wp_unslash( $_POST['vulnwp_status_note'] ) )
	: '';

This is the standard pattern for superglobal input in WordPress. If the code skips wp_unslash(), escaped characters can survive in ways that are annoying for both validation logic and stored content.

Use it on arrays when the whole payload is slashed

The helper works recursively, so it can normalize an input array before field-by-field sanitization. That is useful for structured admin forms, but it still does not mean a single sanitization function can be applied to the whole array blindly.

<?php
$raw = isset( $_POST['vulnwp_settings'] )
	? wp_unslash( $_POST['vulnwp_settings'] )
	: array();

Do not confuse unslashing with sanitization

wp_unslash() only normalizes slash handling. It does not make the value safe for HTML, database storage, JSON, redirects, or business rules. The value still needs the right sanitization and validation step for its actual type.

Apply it where the raw request first enters your logic

The best place for wp_unslash() is near the top of the request-handling path. That keeps later logic cleaner and avoids a codebase where some branches are working with slashed values and others are not.

Common mistakes

• Sanitizing the slashed value directly. This is the classic bug.
• Treating unslash as a security control. It is only a normalization step.
• Applying one sanitizer to a whole mixed array. Each field still needs type-appropriate handling.
• Unslashing too late in the flow. That makes downstream behavior harder to reason about.

Production checklist

• Use wp_unslash() when reading request data from WordPress superglobals.
• Sanitize after unslashing, not before.
• Validate the normalized value for business rules separately.
• Normalize arrays once, then sanitize field by field.
• Keep request handling order consistent across plugins and theme code.

Related reading

Pair this with the sanitize_textarea_field guide for multiline admin input, and with the current_user_can article if the request also performs a privileged action.

References and further reading

• WordPress Code Reference: wp_unslash()
• WordPress Code Reference: sanitize_text_field()
• WordPress Common APIs Handbook: Sanitizing Data