Intervention/image · error · NotSupportedException
Class '{objectShortname}' is not supported by {id} driver
Error message
Class '{objectShortname}' is not supported by {id} driver What it means
Drivers map generic modifiers/analyzers/encoders/decoders to driver-specific classes by naming convention: the same short class name under the driver's namespace (e.g. Gd\Modifiers\ResizeModifier). If that specialized class does not exist for the active driver, specialize() throws NotSupportedException. A generic class without a matching implementation for your driver cannot be applied.
Source
Thrown at src/Drivers/AbstractDriver.php:191
}
// resolve classname for specializable object
$objectShortname = substr($object::class, (int) strrpos($object::class, '\\') + 1);
$specializedClassname = implode("\\", [
substr($this::class, 0, (int) strrpos($this::class, '\\')), // driver's namespace
match (true) {
$object instanceof ModifierInterface => 'Modifiers',
$object instanceof AnalyzerInterface => 'Analyzers',
$object instanceof EncoderInterface => 'Encoders',
$object instanceof DecoderInterface => 'Decoders',
},
$objectShortname,
]);
// fail if driver specialized classname does not exists
if (!class_exists($specializedClassname)) {
throw new NotSupportedException(
"Class '" . $objectShortname . "' is not supported by " . $this->id() . " driver",
);
}
// create a driver specialized object with the specializable properties of generic object
$specialized = new $specializedClassname(...$object->specializationArguments());
// attach driver
return $specialized->setDriver($this);
}
}
View on GitHub (pinned to 5598b9e397)
Solutions
- Check the package of the modifier/analyzer/encoder for driver support and install or enable the implementation for your driver
- Switch the ImageManager to a driver the extension supports (new ImageManager(driver: ...))
- For your own generic classes, place the specialized class in the matching driver namespace (e.g. Drivers\Gd\Modifiers\YourModifier) with the same short name
Example fix
// before: custom modifier only exists for Gd
$manager = new ImageManager(new DriverManager('Imagick'), ...);
// after
$manager = new ImageManager(driver: new \Intervention\Image\Drivers\Gd\Driver()); Defensive patterns
Strategy: validation
Validate before calling
$modifierClass = get_class($modifier);
$specialized = str_replace('\\' . basename(str_replace('\\', '/', $modifierClass)), '', $modifierClass);
// simplest guard: catch and surface which driver is missing support Try / catch
try {
$image->apply($modifier);
} catch (NotSupportedException $e) {
// message names the class and driver - switch driver or add the specialized class
} Prevention
- Verify third-party modifiers support your driver (Gd vs Imagick) before adopting them
- Follow the Drivers\<Driver>\Modifiers|Encoders|Analyzers namespace convention for specialized classes
- Test custom generic classes against every driver you ship
When it happens
Trigger: Running the Imagick driver and applying a modifier/analyzer/encoder that only ships Gd-specific classes (or vice versa); a custom modifier whose specialized class is in the wrong namespace or misnamed relative to the convention.
Common situations: Third-party or in-house modifiers written for one driver only; copying a built-in specialized class into a custom namespace where the naming convention breaks.
Related errors
- Failed to apply Intervention\Image\Drivers\Gd\Modifiers\Blur
- Failed to apply Intervention\Image\Drivers\Gd\Modifiers\Brig
- Failed to apply colorize effect
- Color profiles are not supported by GD driver
- Argument $native must be of type
AI-assisted analysis of Intervention/image@5598b9e397 (2026-08-23).
Data as JSON: /api/errors/f23a4291219f04c3.
Report an issue: GitHub.