Intervention/image · error · ImageDecoderException

Data Uri contains unsupported image type

Error message

Data Uri contains unsupported image type

What it means

DataUriImageDecoder::decode was given a DataUri object; its embedded binary was handed to the binary decoder chain, which threw a DecoderException. The data URI itself parsed fine — the bytes inside it are not an image the GD driver can decode, so the failure is re-thrown as this ImageDecoderException.

Source

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

    /**
     * {@inheritdoc}
     *
     * @see DecoderInterface::decode()
     *
     * @throws InvalidArgumentException
     * @throws DriverException
     * @throws ImageDecoderException
     * @throws StateException
     * @throws NotSupportedException
     */
    public function decode(mixed $input): ImageInterface
    {
        if ($input instanceof DataUri) {
            try {
                return parent::decode($input->data());
            } catch (DecoderException) {
                throw new ImageDecoderException('Data Uri contains unsupported image type');
            }
        }

        if (!is_string($input)) {
            throw new InvalidArgumentException(
                'Image source must be data uri scheme of type string or ' . DataUri::class,
            );
        }

        try {
            return parent::decode(DataUri::parse($input)->data());
        } catch (DecoderException) {
            throw new ImageDecoderException('Data Uri contains unsupported image type');
        }
    }
}

View on GitHub (pinned to 5598b9e397)

Solutions

  1. Inspect the payload: $dataUri->data() then getimagesizefromstring / magic bytes to identify the real content
  2. Reject or rasterize non-raster payloads (SVG -> PNG via rsvg/ImageMagick) before creating the DataUri
  3. Validate at input time when the data URI is a string: decode the base64 part and confirm it is a GD-supported image
  4. Catch ImageDecoderException around read() and surface a meaningful upload error instead of a 500

Example fix

// before
$uri = DataUri::parse($request->input('inline_image'));
$image = $manager->read($uri);
// ImageDecoderException: Data Uri contains unsupported image type

// after
$uri = DataUri::parse($request->input('inline_image'));
if (@getimagesizefromstring($uri->data()) === false) {
    throw new InvalidArgumentException('Inline image must be PNG, JPEG, GIF or WebP.');
}
$image = $manager->read($uri);
Defensive patterns

Strategy: try-catch

Validate before calling

if ($dataUri instanceof \Intervention\Image\DataUri && @getimagesizefromstring($dataUri->data()) === false) {
    throw new RuntimeException('Data URI does not contain a decodable raster image');
}

Type guard

function containsDecodableImage(\Intervention\Image\Interfaces\DataUriInterface $uri): bool
{
    return @getimagesizefromstring($uri->data()) !== false;
}

Try / catch

try {
    $image = $manager->read($dataUri);
} catch (\Intervention\Image\Exceptions\ImageDecoderException $e) {
    // embedded bytes are not GD-decodable; reject or rasterize first
}

Prevention

When it happens

Trigger: ImageManager::read($dataUriObject) (or a direct decoder call) where DataUri->data() yields SVG text, PDF bytes, a truncated image, or a TIFF/HEIC payload. The inner BinaryImageDecoder::decode throws (format failure, empty data, or unmapped MIME) and is wrapped with this message.

Common situations: Rich-text editors (TinyMCE, CKEditor paste-as-image) embedding image data URIs that occasionally carry SVG; DataUri::parse used on unvalidated user strings; payloads that went through HTML encoding and came back with damaged bytes; pipelines storing DataUri objects in session/cache between requests.

Related errors


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