How Blade's @context directive broke our JSON-LD

If you have schema.org JSON-LD inside a Blade template and you upgrade to Laravel 12, you may have just broken those views. Quietly. Without a deprecation warning.

We hit this last week on a blog index running 12.44.0. The page returned HTTP 500 for every visitor for three weeks before anyone noticed. There is a public issue with the same symptom against 12.20+: laravel/framework#56248.

This is the 90-second writeup so you do not waste an afternoon on it.

Symptom

Any Blade view that contains "@context" as a literal key in inline JSON-LD throws:

syntax error, unexpected end of file, expecting "elseif" or "else" or "endif"
(View: /resources/views/blog/index.blade.php)

The view itself parses fine. Every @if/@endif, @foreach/@endforeach, @push/@endpush is balanced. Yet the compiled view in storage/framework/views/ is malformed.

Cause

Laravel 12 added the @context Blade directive as part of the request-scoped Context feature. The trait lives at vendor/laravel/framework/src/Illuminate/View/Compilers/Concerns/CompilesContexts.php.

@context is an opening block directive. It expects a matching @endcontext later in the template.

But schema.org JSON-LD looks like this:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Blog",
    "name": "..."
}
</script>

When the Blade compiler scans the template, it sees the literal text @context inside the JSON, treats it as the opening of a directive block, and waits for @endcontext. None ever appears. The compiler eventually reports the error at the end of the file, with a stack trace that points 200 lines past the actual cause.

If you peek at the compiled file in storage/framework/views/, you can see the bad output:

"<?php $__contextArgs = [];
if (context()->has($__contextArgs[0])) :
if (isset($value)) { $__contextPrevious[] = $value; }
$value = context()->get($__contextArgs[0]); ?>": "https://schema.org",

That was supposed to be a literal JSON key.

Scope

This affects only literal @context text inside a .blade.php file. JSON-LD emitted via json_encode($data), Js::from($data), or @json($data) is unaffected — those write their output through PHP, never through Blade's directive parser.

Fix

Two characters. Escape the @ with another @:

 <script type="application/ld+json">
 {
-    "@context": "https://schema.org",
+    "@@context": "https://schema.org",
     "@type": "Blog",
     ...
 }
 </script>

Blade renders @@context as a literal @context in the rendered HTML. No other JSON-LD keys collide — @type, @id, @graph are not Blade directives — so this is the only character you need to escape.

If your views were cached during the broken state, run php artisan view:clear once. Laravel recompiles modified Blade files automatically on the next request, so you only need this if a stale compiled view is sticking around.

How to find every instance

grep -rn '"@context"' resources/views

Anywhere that pattern appears, escape it. Worth doing as a one-line audit even if your blog index works — you may have JSON-LD in other templates (FAQ schema, Product schema, Breadcrumb schema, Article schema). All of them use @context as a top-level key. All of them break the same way after the upgrade.

We found three locations. One was throwing 500s on every hit. The other two were inside templates that happened not to be visited since the upgrade.

What I would change about Laravel's behavior

A parse-time warning when the Blade compiler sees @context followed by : rather than ( or whitespace would catch this in development. JSON-LD keys are the dominant case for that pattern; user-defined directives almost always take parens or arguments. A heuristic warning seems cheap and high-value.

For now: @@context and move on.

(Disclosure: I work on Apps66, where this bug bit us. The fix is the only point.)