Intervention/image · error · Intervention\Image\Exceptions\ImageDecoderException

Base64-encoded data contains unsupported image type

Error message

Base64-encoded data contains unsupported image type

What it means

Thrown by Base64ImageDecoder when the string decoded from base64 successfully, but the parent BinaryImageDecoder could not turn the resulting bytes into an image (its DecoderException is remapped to this message). So the base64 was fine; the payload is not a format Imagick can read.

Source

Thrown at src/Drivers/Imagick/Decoders/Base64ImageDecoder.php:42

    }

    /**
     * {@inheritdoc}
     *
     * @see DecoderInterface::decode()
     */
    public function decode(mixed $input): ImageInterface
    {
        try {
            $data = $this->decodeBase64Data($input);
        } catch (DecoderException) {
            throw new ImageDecoderException('Unable to Base64-decode image from string');
        }

        try {
            return parent::decode($data);
        } catch (DecoderException) {
            throw new ImageDecoderException('Base64-encoded data contains unsupported image type');
        }
    }
}

View on GitHub (pinned to 5598b9e397)

Solutions

1. Decode and inspect the first bytes: valid images start with known signatures (\x89PNG, \xFF\xD8 JPEG, GIF8)
2. Re-export/re-upload the source file to rule out truncation
3. Check ImageMagick delegate support: convert -list format | grep -i webp (and install delegates)
4. Catch ImageDecoderException at the read() call and reject the upload with a user-facing message

Example fix

// before: trusting any base64 from the client
$image = $manager->read($request->input('image'));

// after: verify decoded bytes look like an image first
$bytes = base64_decode(preg_replace('/\s+/', '', $input), true);
$ok = $bytes !== false && (str_starts_with($bytes, "\x89PNG") || str_starts_with($bytes, "\xFF\xD8") || str_starts_with($bytes, 'GIF8'));
$image = $ok ? $manager->read($input) : throw new InvalidArgumentException('not an image');

$bytes = base64_decode(preg_replace('/\s+/', '', $input), true);
if ($bytes === false || strlen($bytes) < 8) {
    throw new InvalidArgumentException('base64 payload too short to be an image');
}
$sig = substr($bytes, 0, 4);
$known = ["\x89PNG", "\xFF\xD8\xFF", 'GIF8', 'RIFF'];
if (!in_array(substr($sig, 0, 3), array_map(fn ($k) => substr($k, 0, 3), $known), true)) {
    throw new InvalidArgumentException('decoded data has no known image signature');
}

use Intervention\Image\Exceptions\ImageDecoderException;

try {
    $image = $manager->read($base64);
} catch (ImageDecoderException $e) {
    report($e);
    return response()->json(['error' => 'unsupported-image-format'], 422);
}

When it happens

Trigger: $manager->read($base64) where the decoded bytes are: a truncated image file (cut-off upload), plain text or JSON that happened to look base64-ish, an image format the local ImageMagick build lacks delegates for (AVIF, WebP, SVG without rsvg, HEIC), or a zero-signature blob.

Common situations: Client uploads truncated by size limits; receiving base64-of-base64; environments where imagick was compiled without webp/heif delegates so previously working images now fail; error pages or HTML bodies encoded where an image was expected.

Related errors

• Failed to decode unsupported image format from binary data
• Input is not valid Base64-encoded data
• Base64-encoded data contains unsupported image type
• Unable to Base64-decode image from string
• Data Uri contains unsupported image type

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