Fast Image Size Laravel Package

Product Decisions This Supports

• Build vs. buy for image metadata. The package answers one question — "how wide and tall is this image, and what type is it?" — by reading only the header bytes of a local file or remote URL. That replaces hand-rolled header parsing and avoids pulling GD/Imagick into the decision path just to learn dimensions. Adopt rather than build; the surface area is a single class.
• Feature scoping for media ingestion. Cheap dimension lookups unlock user-facing features that must know size before committing to work: remote image import by URL, avatar/cover crop validation, OG/social preview generation, CMS embeds, storing aspect ratio alongside alt text, and emitting width/height on <img> tags to avoid layout shift (a measurable Core Web Vitals win).
• Backfill and migration work. Because it never decodes full images, it is economical to sweep an existing library (S3, CDN, legacy uploads) and populate width/height/type columns that were never captured — a data-quality project that would otherwise look too expensive to schedule.
• Roadmap de-risking for remote sources. v1.3.1 stops discarding response bodies that arrive with a non-200 status. In practice this is exactly the CDN/object-store case: 206 Partial Content from range requests (the library's happy path) and signed URLs now parse instead of failing. Fewer "could not determine image size" errors, fewer failed imports, fewer support tickets.
• A decision the patch forces. The same relaxation means a 403/404/500 that happens to carry image bytes may now parse successfully. If any workflow treats "probe failed" as a proxy for "this URL is dead" (dead-link cleanup, retry logic, alerting), that signal must move to the HTTP layer. Decide this before rollout — it changes the semantics of an existing monitoring feature, not just a dependency version.
• What it does not decide. It reports metadata; it does not transform, re-encode, or thumbnail. If the roadmap includes resizing or format conversion, that is a separate buy (Intervention Image, Glide, imgproxy/Cloudinary) and should be scoped independently.

When to Consider This Package

Adopt it when:

• You need width, height, and image type from local paths or remote URLs and want to avoid downloading or decoding the full asset.
• You are processing remote images at volume — queued imports, feed ingestion, backfills — where per-image memory and CPU are the constraint.
• You are on PHP 8+ with or without Laravel. It is framework-agnostic (no service provider, facade, or config), so it fits commands and jobs as well as controllers; plan a thin wrapper service so the dependency stays swappable.
• Your asset mix is ordinary JPEG/PNG/GIF/WebP/BMP/TIFF/ICO served by CDNs or object storage — precisely what v1.3.1 improves.

Look elsewhere or defer when:

• You need transformations, re-encoding, or thumbnails — this package only reports metadata.
• You need full EXIF, ICC profiles, orientation correction, AVIF/HEIC coverage, or animated-frame data — validate against your actual asset mix first.
• The image is already decoded earlier in the pipeline (e.g. Laravel's image validation rule); a second probe adds latency for no new information.
• Any user-supplied URL can reach the fetcher in a multi-tenant context. The package is not a security boundary; it must sit behind scheme allow-listing, private-IP blocking, timeouts, and size caps. If the team cannot commit to that work now, do not ship the untrusted-URL surface.
• The organization needs a vendor with a support contract — this is a single-maintainer project with infrequent releases, so bus-factor risk is real and should be an explicit accepted risk.

How to Pitch It (Stakeholders)

To executives: A small, single-purpose open-source dependency that tells us an image's dimensions and format by reading a few hundred bytes instead of the whole file. That lowers compute and memory on import and backfill jobs, improves page rendering through correctly sized images, and saves engineering time we would otherwise spend maintaining our own parser. The v1.3.1 patch is a low-risk bug fix that makes remote reads succeed more often against our CDN and object storage, directly reducing failed imports and support load. Cost is effectively zero, risk is low, and it carries no framework lock-in. The one condition we are attaching: any user-supplied URL path ships only after a security review of the fetch layer.

To engineering: Header-only image probing — no GD/Imagick needed for metadata. Pure PHP and framework-agnostic, so it drops into jobs and Artisan commands; wrap it in a thin resolver service and bind the PSR-18 client plus a cache adapter in a service provider so the library stays replaceable. Pin to ^1.3; upstream is a single maintainer, so treat upgrades as deliberate, tested events. Plan around three known characteristics: it returns null/false on failure rather than throwing (handle "unknown dimensions" explicitly or nulls reach the UI), it needs SSRF guards and per-host timeouts at the client layer, and v1.3.1 changed error semantics — probe success no longer implies a 2xx, so keep explicit status validation wherever that distinction drives behavior. Minimum test set before rollout: 200, 206, redirect chains, 404/503 with an HTML body (must be rejected, not misparsed), and truncated responses. Roll out behind a flag on one low-risk surface, such as link previews, before it backs user-facing media metadata.