image-dimensions

This seems to be the affected line: https://github.com/sindresorhus/image-dimensions/blob/aa978c8d17d96a1c73e571689b40cf046fba0a72/index.js#L29 Per caniuse: https://caniuse.com/wf-async-iterable-streams, it seems that asynchronously iterable streams are not supported in Safari (both desktop and mobile)

and return PNG dimensions when the PNG signature is present but the expected chunk is replaced with . The same happens for Apple's variant when the chunk after is not . Actual: Both functions return from bytes that are not an image-header chunk. Expected: Return , consistent with the documented behavior for invalid image data. The parser checks the PNG signature and reads fixed dimension offsets, but does not check the image-header chunk type. Our application currently checks that chunk type before calling the library. Reproduced on at (package version 2.5.1), using Node.js 24.13.0 on macOS. No API keys or external services are required. Minimal reproduction Check out the tested commit (the reproduction needs no dependency installation): With Node.js 24, save the following as in that directory and run : Both calls print ; the expected result is for each. The reproduction deliberately supplies only the header prefix the library reads. The regression tests additionally use copies of the repository's full ordinary and Apple PNG fixtures, replacing only the expected chunk tag. This isolates the missing chunk-type check rather than relying on incomplete dimension fields. The mutation also invalidates the fixture's checksum; checksum validation is not part of the proposed change. Tests and proposed approach I have local regression tests for both entry points and both PNG variants. All four malformed-header assertions fail on the unchanged parser. Four control tests pass, covering valid images, one-byte stream chunks, and truncated input returning without throwing. The existing tests continue to pass, apart from the already-declared expected JPEG XL failure. Would you consider checking for at the expected position before reading dimensions, and would a focused fix with regression tests be welcome? The proposed scope is the chunk tag only, preserving incremental reads and existing Apple PNG support—not full PNG validation or additional formats. I have not changed the parser. The investigation, reproduction, and tests were prepared with OpenAI Codex assistance. I saw your policy on fully AI-generated pull requests and am sharing the reproduction for discussion rather than submitting such a pull request.

Adds and exports it in index.d.ts The README.md wasn't updated to use this new type since I figured you wanted to make the object properties visible, but that might be warranted.