mewebstudio/Purifier for Laravel: HTML cleaning with Eloquent casts
HTMLPurifier for Laravel 5+
At a glance
- What is it?
- mewebstudio/Purifier integrates HTMLPurifier into Laravel applications through a service provider, facade, configurable profiles and optional Eloquent casts. It fits Laravel teams that need server-side HTML cleaning, while its permissive configuration still requires deliberate allowlists.
- Who is it for?
- Adopt mewebstudio/Purifier when Laravel must clean HTML at request, middleware or Eloquent model boundaries, and first verify the allowed tags, attributes, URI rules, cast direction and published cache configuration. It is a poor fit when the application needs a different filtering model, unrestricted markup or validation rules outside the HTMLPurifier allowlist.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 137 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Star history
- mewebstudio/Purifier1,979 ★ · -1
| Repository | 2026-10-16 | 2026-10-23 |
|---|---|---|
| mewebstudio/Purifier | 2k | 2k |
-1 Stars in the last 7 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
What mewebstudio/Purifier does inside Laravel
mewebstudio/Purifier is a Laravel service provider for the PHP library HTMLPurifier. It addresses a specific server-side problem: accepting HTML from a form, request or model while removing unwanted markup and making the result conform to the configured HTML rules. The README presents this as a way to combine a WYSIWYG editor with standards-compliant HTML filtering, rather than reducing input to a limited markup syntax such as BBCode.
The package is intended for Laravel applications that process user-controlled content, including content edited through a browser. The README describes use inside requests or middleware, where cleaning can happen before application logic stores or processes the value. It also documents Laravel 7 and later Eloquent casts, which place the same HTML cleaning capability at the model attribute boundary.
This is not a general-purpose validation package for every input type. The documented calls accept values that may contain HTML and pass them to HTMLPurifier. The published configuration is where the application chooses the permitted elements, attributes, CSS properties and URI behavior. That distinction matters because a sanitizer cannot preserve every editor feature while also applying a restricted allowlist.
How the service provider, facade and casts process HTML
The package registers a Laravel service provider and exposes the Purifier service through a facade. In Laravel 5.5 and later, the README states that the provider is auto-discovered, so an application does not need to add it manually. Older Laravel 5 releases register `Mews\Purifier\PurifierServiceProvider::class` under the `providers` key and `Mews\Purifier\Facades\Purifier::class` under the `aliases` key.
Cleaning can be performed through the facade or through the documented `clean` helper. The second argument selects either a named configuration profile, such as `titles`, or an array of dynamic HTMLPurifier settings such as `array('Attr.EnableID' => true)`. This gives an application a default policy plus narrowly scoped exceptions without requiring a second sanitizer implementation.
The package can also add an HTMLPurifier URI filter through a callback. The README obtains the `URI` definition from `HTMLPurifier_Config`, then adds `HTMLPurifier_URIFilter_NameOfFilter`. That mechanism is relevant when allowed links or embedded content need a more specific URI policy than the default configuration provides.
For Eloquent, `CleanHtml` cleans both when a value is set and when it is retrieved. `CleanHtmlInput` cleans only on input, and `CleanHtmlOutput` cleans only on output. The direction is a meaningful operational choice. Input cleaning changes the value stored in the database, while output cleaning preserves stored content and filters it when the model returns the attribute.
Installing mews/purifier and publishing the policy
For Laravel 5.5 and later, the documented installation starts with Composer. The package is identified as `mews/purifier` in the command, although the repository name is `mewebstudio/Purifier`.
composer require mews/purifierLaravel auto-discovers the service provider according to the README. After Composer completes, the package can be called through the facade in the application code. For Laravel 5.0 to 5.4, the same Composer command is used, but the provider and facade entries must be added manually to `config/app.php`.
The configuration is optional until the application needs a custom policy. Publish it with:
php artisan vendor:publish --provider="Mews\Purifier\PurifierServiceProvider"This creates `config/purifier.php`, according to the README. The file contains the default HTML allowlist, CSS properties, formatting options and additional named profiles such as `test` and `youtube`. The application should inspect these values before sending a real user submission through the package. In particular, the default profile permits only the listed tags and attributes, while `HTML.SafeIframe` and `URI.SafeIframeRegexp` change the policy for the documented YouTube profile.
A first Laravel cleaning call and model cast
The shortest documented use passes request input to `clean`. The README gives both a direct helper form and a facade form:
clean(Input::get('inputname'));A facade call is equivalent from the application's point of view:
Purifier::clean(Input::get('inputname'));The returned value is the cleaned HTML. The README does not provide a sample response or application test command, so the first integration check should compare the saved value with the submitted value and inspect whether tags, attributes and styles outside the configured policy remain.
For a Laravel 7 or later Eloquent model, the documented cast setup is:
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
use Mews\Purifier\Casts\CleanHtml;
use Mews\Purifier\Casts\CleanHtmlInput;
use Mews\Purifier\Casts\CleanHtmlOutput;
class Monster extends Model
{
protected $casts = [
'bio' => CleanHtml::class,
'description' => CleanHtmlInput::class,
'history' => CleanHtmlOutput::class,
];
}The comments in the README identify the behavior: `bio` is cleaned in both directions, `description` when set, and `history` when retrieved. This lets an application decide whether sanitization is a write-time invariant, a read-time safeguard, or both.
Allowlist constraints and URI filtering
The default configuration is intentionally restrictive. Its `HTML.Allowed` value includes elements such as `div`, `strong`, `i`, `a`, `ul`, `li`, `p`, `span` and `img`, but only selected attributes are permitted. The `a` element is limited to `href|title`, and `p` and `span` include `style`. Images are limited to `width|height|alt|src`. Anything outside the policy is outside the documented default allowance, so an editor may appear to support formatting that the configured purifier removes.
The CSS policy is also an allowlist. `CSS.AllowedProperties` names font properties, padding-left, color, background-color and text alignment. A design that depends on arbitrary classes, unsupported CSS properties or JavaScript-related attributes will need an explicit policy change, but the README does not document a separate CSP policy or a general authorization mechanism for arbitrary attributes.
The `youtube` profile illustrates a narrower extension rather than a blanket permission. It enables safe iframes and constrains `URI.SafeIframeRegexp` to the documented YouTube and Vimeo embed URL patterns. The README also shows a URI filter callback, which is useful when the application needs a named HTMLPurifier URI filter. Neither example documents automatic validation of every application URL outside HTMLPurifier's own rules, so URL authorization still needs to be considered separately if the application has domain-specific requirements.
This configuration model is a direct operational constraint. It gives administrators a readable place to define supported markup, but it also means that adoption requires reviewing every field that receives HTML. A permissive editor policy cannot be assumed simply because HTMLPurifier itself supports more HTML.
Alternative approach and maintenance considerations
The direct alternative is integrating HTMLPurifier into Laravel without this package, using a custom service, dependency injection configuration or application-specific service provider. The underlying filtering library is the same. mewebstudio/Purifier adds Laravel-specific installation, a facade, helper-style access, configuration publishing, named profiles and Eloquent cast classes. A direct integration may suit a team that wants to own the wiring and middleware policy, while this package reduces the amount of Laravel-specific adapter code.
Another alternative is storing or rendering the submitted content without server-side HTML filtering, then handling it through a different content policy or editor-specific representation. That approach does not provide the same documented HTMLPurifier allowlist, so it is appropriate only when the application deliberately does not accept arbitrary HTML and has a separate validation design. The README does not compare sanitizer performance, correctness results or security guarantees between these approaches.
The repository is not archived. Its last push was on 2026-06-08, and the release list includes version 3.4.4 dated 2026-04-15. That is evidence of recent project activity, not a guarantee that every Laravel or PHP version combination is supported in every deployment. Upgrading should include reviewing `config/purifier.php`, Laravel compatibility, HTMLPurifier behavior behind the package and application tests for allowed markup.
The project uses the MIT license. That is the repository's stated licensing information and should be checked against the licenses of the package's dependencies during adoption. The README does not document an upgrade command, a migration procedure or a rollback procedure.
Editorial conclusion
Adopt mewebstudio/Purifier when Laravel must clean HTML at request, middleware or Eloquent model boundaries, and first verify the allowed tags, attributes, URI rules, cast direction and published cache configuration. It is a poor fit when the application needs a different filtering model, unrestricted markup or validation rules outside the HTMLPurifier allowlist.
Frequently asked questions
How do I install mewebstudio/Purifier in Laravel 5.5 or later?
Run `composer require mews/purifier`. The README states that the service provider is auto-discovered, so no manual provider entry is needed.
How can I clean HTML in a Laravel Eloquent model?
For Laravel 7 and later, use `Mews\Purifier\Casts\CleanHtml`, `CleanHtmlInput` or `CleanHtmlOutput` in the model's `$casts` array. Choose the cast according to whether the attribute should be cleaned on input, output or both.
Where do I configure the allowed HTML tags and attributes in mewebstudio/Purifier?
Publish the package configuration with `php artisan vendor:publish --provider="Mews\Purifier\PurifierServiceProvider"`, then edit `config/purifier.php`. The default policy is under the `settings.default` key and includes `HTML.Allowed` plus `CSS.AllowedProperties`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mewebstudio-purifier)Star history chart for your README
[](https://hysenlabs.com/projects/mewebstudio-purifier)Was this useful?