Laravel 13.20 Image Processing: A Production Guide

Originally published on letmesend.email. I work on letmesend.email, and this is an adapted edition of that guide.

This article was prepared with AI-assisted editorial support. Its technical claims and examples were tested against Laravel Framework v13.20.0 in an isolated application.

Image handling rarely stays small. An avatar upload becomes a thumbnail, a WebP copy, a storage policy, a validation rule, and eventually a queue job.

Laravel 13.20, released on July 14, 2026, gives this work a first-party home through the new Illuminate\Image component and Image facade. It connects image processing to requests, filesystem disks, configuration, and Laravel's container while keeping transformation pipelines immutable.

This guide focuses on what actually shipped and the production boundaries that still belong in your application.

What first-party image processing means

Laravel applications have used Intervention Image, custom wrappers, and external image services for years. Laravel 13.20 does not make Intervention Image disappear. The built-in GD and Imagick drivers use intervention/image:^4.0 underneath.

The first-party part is the Laravel-facing API:

use Illuminate\Support\Facades\Image;

use RuntimeException;



$thumbnail = Image::fromPath(storage_path('app/source/photo.jpg'))

    ->orient()

    ->cover(640, 360)

    ->toWebp()

    ->quality(80);



$storedPath = $thumbnail->store('thumbnails', 'public');



if ($storedPath === false) {

    throw new RuntimeException('The thumbnail could not be stored.');

}

That chain describes four concerns:

1. Load the source lazily.


2. Record transformations in order.


3. Select an output format and quality.


4. Process and store the result through Laravel's filesystem.

The built-in drivers support GD and Imagick. GD is the default. The default processing quality is 70 unless the pipeline selects another value.

Install and configure a driver

Laravel 13.20 and the image component require PHP 8.3 or newer. Install the suggested processing dependency:

composer require intervention/image:^4.0

Your runtime also needs the extension for the chosen driver:

• GD requires ext-gd.


• Imagick requires ext-imagick and the ImageMagick system library.

The image configuration uses GD by default:

<?php



return [

    'default' => env('IMAGE_DRIVER', 'gd'),

];

To use Imagick as the application default:

IMAGE_DRIVER=imagick

An individual pipeline can choose a different driver without changing global configuration:

use Illuminate\Support\Facades\Image;



$source = Image::fromPath(storage_path('app/source/photo.jpg'));



$gdVariant = $source->usingGd()->cover(400, 400);

$imagickVariant = $source->usingImagick()->cover(400, 400);

Test both drivers with the same representative files in the container you deploy. Output size, memory use, and processing time depend on the source material and extension build.

Create images from supported sources

The component accepts request uploads, local paths, URLs, raw bytes, Base64 strings, and Laravel storage paths.

Request uploads

Validate an upload before asking the image driver to decode it:

use Illuminate\Http\Request;



public function store(Request $request)

{

    $request->validate([

        'avatar' => [

            'required',

            'image',

            'mimes:jpeg,png,webp',

            'max:5120',

            'dimensions:min_width=200,min_height=200,max_width=6000,max_height=6000',

        ],

    ]);



    $image = $request->image('avatar');



    abort_if($image === null, 422, 'A valid avatar image is required.');



    // Build the output pipeline from $image.

}

$request->image('avatar') returns an Illuminate\Image\Image when the input contains one uploaded file. It returns null when it does not.

Other entry points

use Illuminate\Support\Facades\Image;

use Illuminate\Support\Facades\Storage;

use RuntimeException;



$binaryContents = file_get_contents(storage_path('app/source/photo.jpg'));



if ($binaryContents === false) {

    throw new RuntimeException('The source image could not be read.');

}



$base64Contents = base64_encode($binaryContents);



$fromPath = Image::fromPath(storage_path('app/source/photo.jpg'));

$fromUrl = Image::fromUrl('https://assets.example.test/photo.jpg');

$fromBytes = Image::fromBytes($binaryContents);

$fromBase64 = Image::fromBase64($base64Contents);

$fromStorage = Image::fromStorage('originals/photo.jpg', 's3');

$fromDisk = Storage::disk('s3')->image('originals/photo.jpg');

Most sources are lazy. Laravel reads or downloads the actual contents when output or metadata is requested.

Do not pass an untrusted user URL directly to fromUrl(). A controlled downloader should limit redirects and response size, reject private network destinations, set a short timeout, and confirm the media type first.

Immutability changes how variants are built

Every transformation and output option clones the image. The source pipeline does not change.

use Illuminate\Support\Facades\Image;



$source = Image::fromPath(storage_path('app/source/product.jpg'))

    ->orient();



$thumbnail = $source

    ->cover(400, 400)

    ->toWebp()

    ->quality(78);



$detail = $source

    ->scale(width: 1600)

    ->toWebp()

    ->quality(84);



$openGraph = $source

    ->cover(1200, 630)

    ->toJpg()

    ->quality(85);

This makes branching predictable. Adding cover() to $thumbnail cannot accidentally resize $detail.

There is one related boundary: an Image object cannot be serialized. Do not put one on a queued job. Store the original first, then dispatch the storage path or your own asset identifier.

Choose the transformation that matches the layout

Laravel 13.20 exposes these transformations:

Prefer cover() for fixed cards and avatars, contain() when the whole product or logo must remain visible, and scale() for responsive width variants.

Convert and inspect output

Laravel 13.20 provides explicit WebP and JPEG output methods:

use Illuminate\Support\Facades\Image;



$source = Image::fromPath(storage_path('app/source/product.jpg'));



$webp = $source

    ->scale(width: 1200)

    ->toWebp()

    ->quality(82)

    ->optimize();



$jpeg = $source

    ->cover(1200, 630)

    ->toJpg()

    ->quality(85);

toJpeg() is also available as an alias for toJpg().

Using the $webp pipeline created above, you can inspect or export processed output with methods such as:

$width = $webp->width();

$height = $webp->height();

$dimensions = $webp->dimensions();

$mimeType = $webp->mimeType();

$extension = $webp->extension();

$bytes = $webp->toBytes();

$base64 = $webp->toBase64();

$dataUri = $webp->toDataUri();

Store paths and image metadata in the database, not the Image instance or a large Base64 value.

A production avatar workflow

A safe workflow preserves the previous asset until both the new file and database update succeed. The following shortened example shows the important boundary:

use Illuminate\Http\Request;

use Illuminate\Support\Facades\DB;

use Illuminate\Support\Facades\Storage;

use Illuminate\Support\Str;

use RuntimeException;

use Throwable;



public function updateAvatar(Request $request)

{

    $request->validate([

        'avatar' => [

            'required',

            'image',

            'mimes:jpeg,png,webp',

            'max:5120',

            'dimensions:min_width=200,min_height=200,max_width=6000,max_height=6000',

        ],

    ]);



    $source = $request->image('avatar');



    abort_if($source === null, 422, 'A valid avatar image is required.');



    $user = $request->user();



    abort_if($user === null, 401);



    $path = "avatars/{$user->getKey()}/".Str::uuid().'.webp';



    $stored = $source

        ->orient()

        ->cover(512, 512)

        ->toWebp()

        ->quality(82)

        ->storeAs($path, disk: 'public');



    if ($stored === false) {

        throw new RuntimeException('The avatar could not be stored.');

    }



    try {

        DB::transaction(function () use ($user, $path): void {

            $user->forceFill(['avatar_path' => $path])->save();

        });

    } catch (Throwable $exception) {

        Storage::disk('public')->delete($path);



        throw $exception;

    }



    return back()->with('status', 'Avatar updated.');

}

In a full replacement workflow, keep the old path before the transaction and delete it only after the new path is active. Versioned filenames prevent a failed write from destroying the last known good asset.

Move expensive work to a queue

Small avatars may be reasonable to process during a request. Large originals, many variants, and batch imports usually belong on a queue.

A reliable sequence is:

1. Validate and store the original upload.


2. Create an asset record with a pending state.


3. Dispatch a job with the asset identifier or storage path.


4. Load the source from storage in the job.


5. Generate every required variant.


6. Mark the asset ready only after all required writes succeed.


7. Record failures and allow controlled retries.

Keep retry operations idempotent. A job should produce the same variant paths or replace them through an explicit versioning policy.

Production checks worth keeping

The convenient facade does not remove the operational work around image processing:

• Validate MIME type, compressed size, and pixel dimensions before decoding.


• Decide whether animated input is allowed.


• Set web server, PHP, worker memory, and worker timeout limits.


• Cap the number of generated variants.


• Re-encode accepted input instead of keeping an uploaded file as the public derivative.


• Check every storage return value because storage methods return string|false.


• Monitor processing time, failures, and worker memory.


• Clean abandoned originals and partial variants.


• Store final width, height, MIME type, and path with each asset variant.

A small compressed file can expand into a large in-memory bitmap. Test the limits with real source dimensions and formats in your production container.

Should an existing application migrate?

The new API does not require an immediate rewrite. Start with one contained workflow, such as avatars or product thumbnails, then compare the old and new output:

• Crop and scale behavior


• EXIF orientation


• Output dimensions


• MIME type and extension


• File size at the selected quality


• Transparency and background behavior


• Animated input behavior, if supported by the product

If the application depends on Intervention operations that Laravel's smaller API does not expose, keep direct Intervention usage for that workflow. If an external image CDN handles dynamic delivery and caching, Laravel's local component does not automatically replace it.

Laravel 13.20 makes the common path more consistent. It does not eliminate the need for input policy, storage design, queues, observability, or realistic performance testing.

The complete Laravel 13.20 Image facade guide includes every released source, transformation, storage method, a multi-variant avatar controller, responsive image markup, migration guidance, tests, and the exact implementation details verified against the v13.20.0 tag.

Sources

• Laravel Framework v13.20.0 release


• First-party image processing pull request


• Laravel 13.x image documentation


• Released Image class