Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Inky Extra Laravel Package

twig/inky-extra

Twig extension that provides the inky_to_html filter, converting Zurb Inky email templates into responsive, table-based HTML. It brings Inky's component-driven markup to Twig-based apps, letting you write cleaner email layouts that render reliably across mail clients.

View on GitHub
Deep Wiki
Context7

A Twig extension for the inky email templating engine

Frequently asked questions about Inky Extra
How do I install twig/inky-extra in a Laravel app?
Install it with Composer using composer require twig/inky-extra:^3.26 and make sure twig/twig ^3.x is available. Laravel is Blade-first, so you also need a Twig environment, either through TwigBridge or a scoped Twig setup for emails. Register the InkyExtension on that environment before rendering any inky_to_html templates. Pin at least 3.26.0 because that release contains the XSS fix.
Does twig/inky-extra work with Laravel Blade out of the box?
No. twig/inky-extra is a Twig extension that registers the inky_to_html filter; it does not add a Blade directive or replace Laravel's Mailable rendering. A Blade-first Laravel app must introduce a Twig rendering path for emails, which is a dual-templating decision. The contained pattern is to keep Blade for web views and use Twig plus Inky only for email templates.
What does the inky_to_html filter actually do?
The filter takes ZURB Inky email template markup and converts it into responsive, table-based HTML suitable for email clients. It delegates layout compilation to the Inky engine and is used inside Twig templates, for example by piping a template string through inky_to_html. It does not inline CSS, test client rendering, or handle delivery; those remain part of your email pipeline.
Which Laravel and PHP versions are supported by twig/inky-extra?
The package is framework-agnostic and does not ship Laravel-specific version constraints; its main dependency is Twig 3.x. In Laravel, support depends on your Twig integration layer, such as TwigBridge or a custom scoped Twig environment, and on the PHP version those packages require. Check the Composer constraints for twig/twig, twig/inky-extra, and your Twig bridge before upgrading Laravel or PHP.
Is twig/inky-extra safe for rendering untrusted content in emails?
Version 3.26.0 explicitly fixes an XSS issue tracked as CVE-2026-46637 and pre-escapes input on HTML-emitting filters, so any adoption should pin twig/inky-extra >=3.26.0. That fix is reassuring, but rendering dynamic user content into HTML through an email filter is still an attack surface. Enforce Twig autoescaping, avoid raw filters on user input, and treat email templates as security-sensitive code.
How should I test Inky email templates in a Laravel project?
Add a CI step that compiles every Twig email template through inky_to_html so malformed Inky markup fails the build. Unit-test your renderer or Mailable wrapper for expected HTML fragments and escaping behavior. Compilation tests do not prove client rendering, so keep a real client QA loop with Litmus or Email on Acid for Outlook, Gmail, and mobile layouts.
Can I use twig/inky-extra for emails without converting my whole Laravel app to Twig?
Yes. The pragmatic pattern is a scoped Twig environment dedicated to emails, registered in a service provider and pointed at resources/views/emails, with InkyExtension added to that environment. Keep Blade for web views and Laravel's normal Mailable flow where possible, and centralize email rendering in one service or base class. This bounds the dual-engine cost to the email surface instead of spreading Twig across the application.
What are the alternatives to twig/inky-extra for Laravel email templates?
If you are Blade-native, alternatives include using ZURB Inky directly in a build step or Node CLI, adopting MJML, or staying with Laravel Markdown mail views and a CSS inliner. twig/inky-extra makes sense mainly when you already render email views through Twig, such as Symfony/Twig or Laravel with TwigBridge. Inky itself is independently consumable, so the Twig extension is a convenience layer rather than the only path.
Is twig/inky-extra actively maintained and production-ready?
It is MIT-licensed and has a recent security release in v3.26.0, which shows maintenance activity. The public signal is still thin at roughly 166 GitHub stars and zero dependents, so there is limited peer hardening to lean on. Treat it as a small, bounded dependency, assign an owner for CVE patching, and keep the ability to call Inky directly if the extension stalls.
Does Inky support dark mode, AMP emails, or interactive email components?
No. Inky is an opinionated table-based email layout engine, and dark mode, AMP for Email, and heavy client-side interactivity are outside its scope. If those are roadmap requirements, twig/inky-extra is the wrong tool regardless of its Twig integration quality. Confirm design constraints with stakeholders before adopting it.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
andydefer/laravel-notification
adachsoft/cli-process-tester
jhaskell13/laraflow
sebastienheyd/boilerplate-media-manager
ccast/tagixo-primix
pretendtrue/laravel-builder
sawmainek/laravel-scout-tntsearch-driver
tomshaw/laravel-calendar-table
dibakar/laravel-ownership
steadrun/laravel-monitor
labyrinthe/connect-laravel
elmogy/layan
drewdan/sentinel-client
dskripchenko/laravel-llm
fatryst/nuonuo
stevenay/myanfont
gmostafa/php-graphql-client
xeviant/paystack
snowsoft/faker
meditationsteps/blogetc