Laravel Excel 4.0: A Wrapper Around PhpSpreadsheet for Eloquent Exports and Imports
🚀 Supercharged Excel exports and imports in Laravel
At a glance
- What is it?
- Laravel Excel packages PhpSpreadsheet behind an export and import API for Laravel, with chunked reads and writes and queue support. Version 4.0 requires Laravel 12 or newer and PHP 8.3, and the 3.1 line is now CVE-only.
- Who is it for?
- Adopt Laravel Excel 4.0 if you are on Laravel 12 or 13 with PHP 8.3 and want Eloquent-aware imports and exports without touching PhpSpreadsheet directly. Stay on 3.1, or on raw PhpSpreadsheet, if you are pinned below those versions or only need to read a handful of cells in a script that has no Laravel container.
- 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 15 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 September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Laravel Excel Solves for Eloquent Applications
PhpSpreadsheet is a spreadsheet library, not an application library. It gives you worksheets, cells and writers, and it asks you to drive all of that yourself. Laravel Excel is the layer above: the README calls it "a simple, but elegant Laravel wrapper around PhpSpreadsheet exports and imports". The target reader is a Laravel developer who already has Eloquent models and now needs a file that a finance team can open in Excel, or needs to ingest a file that a supplier emails every Monday.
The wrapper matters because Laravel already has the pieces that spreadsheet code usually reinvents. Queues become the place where a slow export runs. Validation and dependency injection become the way an import row is checked and handled. Collections become the thing you export. If your application is not Laravel, this package has nothing to offer you; the coupling is the point, not a side effect.
The feature list in the README is short and concrete: export collections to Excel or CSV, export queries with automatic chunking, queue exports, import workbooks and worksheets into Eloquent models with chunk reading and batch inserts, queue each chunk of an import, and export a Blade view rendered as an HTML table into a spreadsheet.
How the PhpSpreadsheet Wrapper Handles Queries, Chunks and Queues
The mechanism is delegation with a scheduling layer on top. Your code supplies a query or a collection; the package drives PhpSpreadsheet to write the file. For large result sets the README says you "provide us the query, we handle the performance", and the two named techniques are automatic chunking for exports and chunk reading with batch inserts for imports. Chunking is what keeps a large export from loading an entire table into memory at once, and batch inserts are what keep an import from issuing one INSERT per row.
Queuing changes where the work happens rather than how the file is produced. The README states that you "can queue your exports so all of this happens in the background", and for imports that "you can queue every chunk of a file". So a single import job can fan out into several chunk jobs. That is a different operational shape from a synchronous import: you need a running worker, and you need somewhere for failures to land.
The Blade view exporter takes a different route to the same output. Instead of mapping rows to cells in PHP, you write an HTML table in a Blade view and the package exports it. For teams that already build tables in Blade, this avoids maintaining a second layout definition. It also means the layout is bound to HTML table semantics, which is a narrower vocabulary than the cell styling API that PhpSpreadsheet exposes.
The repository layout reflects the same layering: src/ holds the package code, config/ holds the publishable configuration, resources/ holds the views used by the Blade exporter, and the phpstan baseline files are split by concern, including separate baselines for PSR cache behaviour before and after version 3 and for queue attributes before Laravel 13.
Installing Laravel Excel and Running a First Import
The package installs through Composer under the name maatwebsite/excel, which is also how Packagist and the badges in the README refer to it. The README does not print an install command, so the version you get depends on the constraints in composer.json and on your Laravel version. The supported-versions table is the authority here: 4.0 targets Laravel >=12 and <=13.x with PHP ^8.3, while 3.1 covers Laravel >=5.8 through <=13.x with PHP ^7.2 or ^8.0.
After that, write an import class in your application. The README points to the quickstart at docs.laravel-excel.com for a first export; the same documentation site hosts the import guide. The package ships a config/ directory and a resources/ directory, which are the two things Laravel packages normally publish with vendor:publish, though the README does not spell out the publish command or the config keys.
A first real use is an Eloquent import. The README describes importing "workbooks and worksheets to Eloquent models with chunk reading and batch inserts", which is the workflow to build: a class that maps each row to a model, registered with the package, then dispatched either inline or through the queue. The documentation site, not the README, is where the class contract and the registration call are defined, so budget time for reading it before you write code.
Version 4.0, the 3.1 CVE-Only Line and the Laravel 12 Floor
The supported-versions table is the most important thing on the README, and it is easy to skim past. Version 3.1 is marked "No active support, CVE only". Version 2.1 and 3.0 are unsupported outright. Only 4.0 is listed as "New features". If you are running 3.1 in production, you are on a branch that receives security fixes and nothing else, and the next feature you want will not arrive there.
Version 4.0 also raises the floor. It requires Laravel >=12 and PHP ^8.3, where 3.1 reached back to Laravel 5.8 and PHP 7.2. An application still on Laravel 10 or PHP 8.1 cannot take 4.0 at all, and the upgrade is therefore a framework upgrade first and a package upgrade second. That ordering matters when you plan the work: the package is not the hard part.
The repository carries UPGRADE-4.x.md at the top level, which is where the breaking changes for the major version are recorded. Read it before touching composer.json. The release history shows 4.0.1, 4.0.2 and 4.0.3 arriving between 2026-08-18 and 2026-09-14, so the 4.x line is receiving patch releases; the last push to the repository was on 2026-09-14. Patch cadence is not the same as a stability guarantee, but it does mean fixes are landing.
Where Laravel Excel Is the Wrong Tool
The clearest boundary is the framework itself. Laravel Excel is a Laravel package. If you are writing a Symfony application, a WordPress plugin, a standalone CLI tool or a one-off migration script, the wrapper gives you nothing and the dependency pulls Laravel components in behind it. Raw PhpSpreadsheet is the correct choice in all of those cases, because it is the library Laravel Excel wraps.
The second boundary is scope. If you need to read a value from one cell, or write a small CSV from an array, a full framework integration is overhead. The package's value comes from chunking, batching and queueing, and none of those matter for a file with forty rows.
The third is the queue. Queued exports and queued import chunks only work if a worker is running and if your infrastructure tolerates background jobs. The README states that queueing is available, but it says nothing about what happens when a queued export fails, whether partial files are cleaned up, or how a half-finished chunked import is retried. Those are real operational questions and the README does not answer them. Treat the queue integration as something you must design around, not something the package resolves for you.
Finally, the Postcardware clause is unusual enough to mention. The code is MIT licensed, and the README separately asks that if the package "makes it to your production environment", you send a postcard to the Spartner address in Meerssen, Netherlands. It is a request, not a condition, but it is a request the maintainer makes explicitly.
Laravel Excel Against Raw PhpSpreadsheet and Laravel Nova Excel
The real alternative is PhpSpreadsheet on its own. The difference is not capability, since Laravel Excel delegates to it; the difference is who owns the plumbing. With PhpSpreadsheet you construct the spreadsheet, iterate your rows, and manage memory and file writing yourself, and you can do that inside a Laravel queued job just as easily. You also keep full access to the cell, style and reader APIs without going through an abstraction. What you give up is the Eloquent-shaped import path, the automatic chunking described in the README, and the Blade view exporter.
A second option in the same family is Laravel Nova Excel, which the README links as a separate package from the same maintainer. That is for exporting inside Nova admin panels, so it is an addition rather than a substitute: it assumes Nova is installed. If you do not use Nova, it is irrelevant.
For most Laravel applications the decision comes down to volume and repetition. One export, written once, is fine in PhpSpreadsheet. Many exports and imports across a codebase, each with its own column mapping, is where a shared wrapper earns its place.
Maintenance Cadence, Licence and Upgrade Cost
The repository was last pushed on 2026-09-14, the same day 4.0.3 was released, and it is not archived. The 4.x branch is where new features go. If you adopt 4.0, your upgrade path is the 4.x line, and UPGRADE-4.x.md exists precisely because moving from 3.1 to 4.0 is not a drop-in change. The supported-versions table also warns that "versions will be supported for a limited amount of time", so the 4.0 window is finite and you should expect another major version eventually.
The licence is MIT, which permits commercial and closed-source use. The Postcardware request sits alongside the licence rather than inside it; the README frames it as an appreciation, not a legal term. Nothing in the repository suggests the licence restricts what you can build. This is a description of what the repository states, not legal advice, and if the MIT terms matter to your organisation, read LICENSE in the repository and get your own counsel.
The upgrade cost is dominated by the version floors. Moving to 4.0 means Laravel 12 or 13 and PHP 8.3 or newer, so the work is the framework upgrade plus a review of your export and import classes against UPGRADE-4.x.md. Staying on 3.1 avoids that work today and leaves you on a branch the README describes as CVE-only.
Editorial conclusion
Adopt Laravel Excel 4.0 if you are on Laravel 12 or 13 with PHP 8.3 and want Eloquent-aware imports and exports without touching PhpSpreadsheet directly. Stay on 3.1, or on raw PhpSpreadsheet, if you are pinned below those versions or only need to read a handful of cells in a script that has no Laravel container. Before you commit, run composer require maatwebsite/excel on the target branch and confirm the resolved version, then read UPGRADE-4.x.md for the changes that affect your existing export and import classes.
Frequently asked questions
How do I install Laravel Excel?
Install it with Composer under the package name maatwebsite/excel. The README does not print the command itself, but it does publish the supported-versions table, so check that your Laravel and PHP versions match the line you are installing: 4.0 needs Laravel 12 or 13 and PHP 8.3, while 3.1 reaches back to Laravel 5.8 and PHP 7.2.
What is Laravel Excel?
It is a Laravel wrapper around PhpSpreadsheet for exports and imports. The README describes it as "a simple, but elegant Laravel wrapper around PhpSpreadsheet exports and imports", and the feature list covers collection exports to Excel or CSV, chunked query exports, queued jobs, and imports into Eloquent models with batch inserts.
How can I export data from Laravel to Excel?
The README lists three routes: export a collection directly, export a query with automatic chunking, or render an HTML table in a Blade view and export that. Large exports can be queued so the work runs in the background. The quickstart for exports lives on the documentation site linked from the README.
What is the difference between Laravel Excel and PhpSpreadsheet?
Laravel Excel wraps PhpSpreadsheet rather than replacing it, so the underlying reader and writer are the same. The wrapper adds the Laravel-shaped parts: exporting collections and queries, chunk reading with batch inserts into Eloquent models, queueing, and the Blade view exporter. PhpSpreadsheet on its own is the better fit outside Laravel.
How do I use Laravel Excel?
You supply a collection or a query for exports, or an import class that maps rows to Eloquent models, and the package drives PhpSpreadsheet behind the scenes. The README points to the quickstart and the documentation site for the concrete class contracts, and to the blog for articles and tutorials.
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/spartnernl-laravel-excel)