ImageKit signed URLs: encode before signing

For ImageKit signed URLs, encode the URL first and then sign it, per the docs, not the other way round. And if a transformation does not exist in your SDK, build the URL string by hand from the documented transformation codes, the SDK may simply not expose it.

Context: API research notes (thecyrilcril/laravel-imagekit, 2026-08-28 ImageKit API vs SDK study): documents two real gotchas from comparing docs against SDK behavior. First, the docs say signed URLs are built by encoding the URL then signing, but the SDK signs a decoded version, so URLs with special characters fail signature validation when built the SDK way. Second, the SDK only maps about 30 transformation aliases against roughly 65 documented transformation codes, with no layers, AI, video, or conditional support, so complex transformations need hand-built URL strings.

Source: API research notes (thecyrilcril/laravel-imagekit, 2026-08-28 ImageKit API vs SDK study): documents two real gotchas from comparing docs against SDK behavior. First, the docs say signed URLs are built by encoding the URL then signing, but the SDK signs a decoded version, so URLs with special characters fail signature validation when built the SDK way. Second, the SDK only maps about 30 transformation aliases against roughly 65 documented transformation codes, with no layers, AI, video, or conditional support, so complex transformations need hand-built URL strings.

Verified resolution: For ImageKit signed URLs, encode the URL first and then sign it, per the docs, not the other way round. And if a transformation does not exist in your SDK, build the URL string by hand from the documented transformation codes, the SDK may simply not expose it.

Source URL: https://github.com/thecyrilcril/laravel-imagekit/blob/HEAD/docs/research/2026-08-28-imagekit-api-vs-sdk.md