Intervention/image · error · ImageDecoderException

Intervention\Image\EncodedImage contains unsupported image t

Error message

Intervention\Image\EncodedImage contains unsupported image type

What it means

EncodedImageObjectDecoder::decode accepted the EncodedImage object, but decoding its ->toString() binary payload through the parent binary chain raised a DecoderException. The wrapped bytes are not an image the GD driver can decode — unsupported format, corrupt data, or truncated content — so an ImageDecoderException with this message is thrown.

Source

Thrown at src/Drivers/Gd/Decoders/EncodedImageObjectDecoder.php:49

     *
     * @see DecoderInterface::decode()
     *
     * @throws InvalidArgumentException
     * @throws ImageDecoderException
     * @throws DriverException
     * @throws StateException
     * @throws NotSupportedException
     */
    public function decode(mixed $input): ImageInterface
    {
        if (!$input instanceof EncodedImageInterface) {
            throw new InvalidArgumentException('Image source must be of type ' . EncodedImage::class);
        }

        try {
            return parent::decode($input->toString());
        } catch (DecoderException) {
            throw new ImageDecoderException(EncodedImage::class . ' contains unsupported image type');
        }
    }
}

View on GitHub (pinned to 5598b9e397)

Solutions

  1. Inspect the payload: $encodedImage->toString(), check strlen and magic bytes, and try getimagesizefromstring on it
  2. Switch the reading manager to ImagickDriver for TIFF/HEIC/JP2-class content, or pre-convert the bytes to PNG/JPEG
  3. Re-create the EncodedImage from a verified source file instead of a possibly damaged serialized copy
  4. Catch ImageDecoderException in the worker and dead-letter the job with the failing payload attached for inspection

Example fix

// before
$image = $manager->read(new EncodedImage($tiffBytes, 'image/tiff'));
// ImageDecoderException: Intervention\Image\EncodedImage contains unsupported image type

// after
$imagickManager = new \Intervention\Image\ImageManager(new \Intervention\Image\Drivers\Imagick\Driver());
$image = $imagickManager->read(new EncodedImage($tiffBytes, 'image/tiff'));
Defensive patterns

Strategy: try-catch

Validate before calling

$bytes = $encodedImage->toString();
if ($bytes === '' || @getimagesizefromstring($bytes) === false) {
    throw new RuntimeException('EncodedImage payload is not GD-decodable; convert or use Imagick');
}

Try / catch

try {
    $image = $manager->read($encodedImage);
} catch (\Intervention\Image\Exceptions\ImageDecoderException $e) {
    // wrapped bytes unsupported on GD; dead-letter the job and inspect payload
}

Prevention

When it happens

Trigger: ImageManager::read(new EncodedImage($bytes, 'image/tiff')) with TIFF/HEIC/SVG/ICO bytes on the GD driver; EncodedImage objects rebuilt from queue payloads whose binary was damaged in transit; encoded images produced by another driver/version and replayed against GD; empty byte payloads in the value object.

Common situations: Queue/job systems serializing EncodedImage objects (or their raw parts) between workers with different GD capabilities; multi-format ingest pipelines where TIFF/HEIC sneak in; cached encode results from v2 being re-decoded by v3; payloads that were JSON-escaped and lost bytes.

Related errors


AI-assisted analysis of Intervention/image@5598b9e397 (2026-08-23). Data as JSON: /api/errors/57ca5cc009554f53. Report an issue: GitHub.