iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Blade templates are harder to format than ordinary HTML because they combine HTML with Blade directives and PHP expressions. An HTML formatter understands elements and attributes; a Blade-aware formatter must also understand conditions, loops, component syntax, and directive nesting. If your formatter leaves @if, @foreach, or component markup at the wrong indentation, the solution is to use a formatter that explicitly parses Blade rather than treating the file as plain HTML.
The practical choices are Laravel Pint with its opt-in Blade rule, a locally installed Prettier setup with a Blade plugin, or the standalone blade-formatter package. Each can produce consistent output, but complex templates still require diff review because directive boundaries and HTML tags can interact in ways a formatter cannot always infer safely.
Why Blade formatting is different from HTML formatting
A file ending in .blade.php is a Laravel view template. It commonly contains normal HTML plus Blade directives that echo values, branch with conditions, iterate over data, include components, and control sections. Laravel’s Views documentation describes Blade templates as HTML combined with directives for output, if statements, iteration, and other template behavior.
An HTML formatter builds a tree from opening and closing tags. Blade adds another tree around that markup. For example, an @if and @else pair has a logical relationship even though neither is an HTML element. A loop may contain several sibling elements, and a component attribute may contain a PHP expression or another directive. The formatter has to preserve both structures at once.
#1 Best Overall
This is why an HTML-only formatter may produce technically valid HTML indentation while making the template’s control flow difficult to read. It may also leave directives flush against the margin, indent an @else as if it were ordinary text, or wrap attributes without understanding Blade’s delimiters. That does not mean every HTML formatter fails on every Blade file; it means a formatter without suitable Blade parsing cannot be expected to format template constructs consistently.
A small example of the two structures
<div class="profile-card">
@if ($user->isAdmin())
<span class="badge">Administrator</span>
@else
<span class="badge">Member</span>
@endif
</div>The outer HTML element and the inner conditional both need predictable indentation. A Blade-aware formatter can usually make that relationship visible; an HTML parser alone may not recognize the directive body as a nested block.
What Laravel officially provides: Pint’s opt-in Blade formatter
Laravel Pint does not format Blade files by default. The Laravel 13.x Pint documentation describes Blade formatting as an opt-in rule named Pint/laravel_blade. You can enable it in your project configuration or apply it for one run from the command line.
Recommended Free Tools
Run Blade formatting once
- Install Pint as a project dependency if it is not already present.
- From the project root, run
./vendor/bin/pint --blade. - Inspect the changed files with your version-control diff before committing.
The one-time command is useful when you want to see how the formatter changes an existing codebase without changing the team’s permanent configuration.
Enable the rule for repeatable formatting
Add the documented Pint/laravel_blade rule to pint.json. A typical configuration keeps your existing preset and turns the rule on:
{
"preset": "laravel",
"rules": {
"Pint/laravel_blade": true
}
}After that, running ./vendor/bin/pint applies the Blade rule along with the rest of your Pint configuration. Keep the configuration in version control so every developer and CI job uses the same behavior.
Dependencies and skipped files
Pint’s documented Blade implementation uses Prettier together with prettier-plugin-blade and prettier-plugin-tailwindcss. Node.js and the related Prettier dependencies therefore need to be available in the environment where Pint formats Blade files. A PHP-only installation is not sufficient for this path.
The Pint documentation also says it automatically skips certain files, including email views in resources/views/emails and resources/views/mail. If those views are not being changed, check whether an automatic exclusion explains the result before troubleshooting your syntax.
Using Prettier directly with a Blade plugin
A direct Prettier workflow is useful when your editor already runs Prettier for JavaScript, CSS, or HTML and you want one command to cover Blade as well. Install the Blade plugin in the project rather than relying only on a globally installed editor extension. The plugin’s documentation specifically expects a local project installation.
Install and configure the parser
Install Prettier and the Blade plugin as development dependencies, then configure Blade files to use the blade parser. The following is an example of the documented configuration style; adjust widths and wrapping to match your project:
Rank #3
{
"plugins": [
"prettier-plugin-blade",
"prettier-plugin-tailwindcss"
],
"overrides": [
{
"files": "*.blade.php",
"options": {
"parser": "blade",
"tabWidth": 4,
"printWidth": 120,
"singleAttributePerLine": true
}
}
]
}The Blade plugin provides parser settings for indentation, print width, and attribute wrapping. The Tailwind plugin can sort utility classes when that behavior is enabled in your project. Treat class sorting as a separate style decision: it changes class order, while Blade parsing controls directive and markup structure.
Free tools Windows power users keep installed
One-click scans. No signup required.
Editor integration
The plugin documents integrations for VS Code, Vim, JetBrains IDEs, and Nova. In each editor, select the project’s Prettier installation as the formatter and associate it with *.blade.php. Enable format-on-save only after running it manually on representative files; otherwise a complex template can be reformatted every time it is saved before you have reviewed the result.
Ignoring selected code
When a generated fragment, embedded script, or deliberately unusual layout should not be touched, use the ignore mechanisms documented by the plugin. It supports Blade or HTML comments to exclude selected code. Keep exclusions narrow and explain them in a nearby comment so another developer knows why that section is not being normalized.
Standalone blade-formatter: when a separate package fits better
The standalone blade-formatter project is another option for teams that want a dedicated Blade command-line tool rather than Pint’s Laravel-centered workflow. Its documented features include a .bladeformatterrc.json configuration file, a .bladeignore file, and integrations such as VS Code and coc.nvim.
Configuration areas
Its configuration covers the decisions teams normally need to settle:
- Indentation size and style.
- Attribute wrapping and maximum line length.
- Optional Tailwind class sorting.
- The PHP language version used when parsing embedded PHP.
- Whether PHP syntax checking is performed.
Use the option names and accepted values from the release installed in your project. The project’s own list mentions custom directives and @for support, so do not assume that every release handles every directive exactly like Laravel’s built-in syntax. Pin the package version and test templates containing your custom directives before making it the only formatter in CI.
Ignoring files and sections
Put generated or intentionally exceptional files in .bladeignore instead of relying on individual developers to remember special commands. For a single section, use the formatter’s documented ignore comments. Ignoring a file is safer than repeatedly fighting a formatter over generated output, but it also means that file will not receive ordinary indentation fixes.
Blade formatting and PHP formatting are separate problems
PHP code can appear inside Blade expressions, directives, and statements, but formatting PHP files and parsing a Blade template are different tasks. A PHP formatter or Prettier’s PHP plugin can format standalone PHP sources and may help with PHP fragments, yet it does not by itself establish support for Blade directives.
Choose a workflow that answers both questions:
- How are
.phpclasses and standalone PHP files formatted? - How are
.blade.phpdirectives, tags, attributes, and embedded expressions formatted together?
Do not install a PHP formatter expecting it to indent @if, @foreach, components, or Blade comments. Those constructs require a Blade-aware parser or formatter.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What happens with complex directive and tag combinations
The Prettier Blade plugin documents an important limitation: indentation can be incorrect when opening and closing HTML tags cross or interact unusually with @if/@else branches. Consider a structure in which an element starts in one branch and closes in another, or where a conditional appears between a tag’s opening and closing pieces. HTML nesting and directive nesting then disagree, leaving no unambiguous tree for a formatter to follow.
This is a documented edge case, not evidence that Blade formatting is universally unreliable. You can reduce the risk by keeping each branch structurally complete:
@if ($showPanel)
<section class="panel">
<h2>Details</h2>
</section>
@else
<p>No details available.</p>
@endifPrefer this over opening a <section> before the conditional and closing it after @endif. When a formatter produces a surprising change, inspect the diff immediately and either simplify the markup, add a narrow ignore comment, or preserve the file with a documented exclusion.
Choosing a workflow
| Option | Best fit | Key requirements | Important limits |
|---|---|---|---|
Laravel Pint with --blade or Pint/laravel_blade |
Laravel projects that already standardize on Pint | Node.js plus the Prettier and Blade-related dependencies used by Pint | Blade support is opt-in; some email-view paths are skipped automatically |
Prettier with prettier-plugin-blade |
Teams wanting editor-first formatting and one Prettier workflow | Local project installation, parser configuration, and editor setup | Complex directive/tag crossings can receive incorrect indentation |
Standalone blade-formatter |
Teams wanting dedicated Blade configuration and ignore files | Package configuration, optional PHP syntax checking, and editor integration | Verify support for custom directives and @for against the installed release |
There is no published controlled benchmark in the documented material that establishes one option as the most accurate or fastest. Base the decision on your existing Laravel and editor workflow, dependency policy, required configuration, and the complexity of your templates.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallA reliable rollout for a real project
- Inventory the templates. Include ordinary views, components, layouts, email views, vendor-published templates, and generated files. Note custom directives and templates with unusual tag boundaries.
- Pick one formatter path. Avoid running Pint, a direct Prettier command, and a standalone formatter over the same files unless you have verified that their outputs are compatible.
- Pin dependencies. Commit the package lockfile and keep Node.js, Prettier, the Blade plugin, and any Tailwind plugin consistent between local development and CI.
- Format a representative sample. Include nested conditionals, loops, components with many attributes, inline PHP, and the most complex layout in the project.
- Review the diff. Check that directive branches remain readable, attributes retain their meaning, Tailwind classes are reordered only when intended, and no content changed beyond whitespace or approved class sorting.
- Document exceptions. Add ignore comments or entries for generated sections and explain the reason.
- Automate checks. Run the same formatter command in CI that developers run locally. A check-only mode, where supported by your chosen tool, should fail the build when files are not formatted rather than rewriting them silently.
Troubleshooting common failures
Nothing happens to a Blade file
Confirm that the file name ends in .blade.php, that your command includes Blade support, and that the file is not under an automatically skipped path such as the documented email-view directories. With Pint, plain ./vendor/bin/pint does not enable Blade formatting unless the rule is in pint.json.
The editor says the parser or plugin is missing
Install the plugin in the project and ensure the editor is using that local dependency. Restart the editor after changing the configuration, then run the formatter from the project root so it can resolve the same package versions used by CI.
Formatting changes every save
Check that only one formatter is registered for *.blade.php. Conflicts between an HTML formatter, a direct Prettier extension, and a Laravel plugin can produce alternating output. Disable duplicate format-on-save providers and keep one canonical command.
Indentation is still wrong in one template
Look for tags that open in one directive branch and close in another, directives inserted inside an attribute list, or custom directives the formatter does not recognize. Make each branch contain complete markup where possible. Otherwise isolate the smallest problematic section with an ignore comment and retain a diff review in code review.
Quick Recap
Practical rules for maintainable Blade templates
- Keep conditional branches structurally parallel so each branch opens and closes its own elements.
- Prefer components and partials over deeply nested mixtures of PHP, directives, and markup.
- Use one project-wide print width, indentation size, and attribute-wrapping policy.
- Do not treat formatter output as a semantic validator; run your normal PHP, view, and application tests as well.
- Review automated formatting changes, especially when a template contains JavaScript, Alpine-style attributes, raw HTML, or generated content.
- Update formatter packages deliberately and recheck representative templates after upgrades.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
