Possible bug

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "import 'sharp'" completes without error.

When an SVG gives its width and height in physical units (pt, in), the density input option seems to be applied twice. The rendered size grows with the square of density/72 instead of linearly. SVGs sized in px or unitless scale correctly.

This makes small SVGs fail with Input image exceeds pixel limit. In our case a 700pt SVG loaded at density 1080 renders at about 157,000px per side instead of 10,500px.

Reproduced with every version from sharp 0.34.5 (libvips 8.17.3, librsvg 2.61.2) to 0.35.5 (libvips 8.18.7, librsvg 2.63.2):

Platforms: macOS 26.6 arm64, and linux x64 in Docker. Node 24.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

System:
OS: Linux 7.0 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
CPU: (4) x64 VirtualApple @ 2.50GHz
Memory: 3.54 GB / 7.75 GB
Container: Yes
Shell: 5.2.21 - /bin/bash
Binaries:
Node: 24.15.0 - /usr/local/bin/node
Yarn: 1.22.22 - /usr/local/bin/yarn
npm: 11.12.1 - /usr/local/bin/npm
pnpm: 10.33.0 - /usr/local/bin/pnpm
npmPackages:
sharp: 0.35.5 => 0.35.5

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

• To auto-orient pixel values use the parameter-less rotate() operation.

• To retain EXIF Orientation use keepExif().

• Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

Included a small javascript code to reproduce this.

What is the expected behaviour?

All three SVGs are the same size: 700pt = 9.7222in = 700px at 72 dpi. They should all render at 1400px at density 144 and 2917px at density 300. The pt and in results match 700 × (density/72)², which suggests the density is applied both when converting units to pixels and again as the render scale.

Sharp only passes dpi to libvips svgload, so I suspect this is in libvips svgload or librsvg rather than sharp itself. I haven't been able to test libvips or librsvg on their own to confirm.

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

import sharp from 'sharp';

const svg = (size) =>
  Buffer.from(
    `<svg xmlns="http://www.w3.org/2000/svg" width="${size}" height="${size}" viewBox="0 0 700 700"><rect width="700" height="700"/></svg>`,
  );

for (const size of ['700', '700pt', '9.7222in']) {
  for (const density of [72, 144, 300]) {
    const { width } = await sharp(svg(size), { density }).metadata();
    console.log(`${size.padEnd(9)} density ${String(density).padEnd(3)} -> ${width}px`);
  }
}

Actual output (sharp 0.35.5)

700       density 72  -> 700px
700       density 144 -> 1400px
700       density 300 -> 2917px
700pt     density 72  -> 700px
700pt     density 144 -> 2800px
700pt     density 300 -> 12153px
9.7222in  density 72  -> 700px
9.7222in  density 144 -> 2800px
9.7222in  density 300 -> 12153px

Please provide sample image(s) that help explain this problem

The inline SVG above is enough to reproduce it. Our real file was a potrace-generated logo with width="700.000000pt" height="700.000000pt".

(I used Claude to describe the problem better, but I have run the commands myself to verify things.) As the text above states, this may not be a bug in sharp itself but rather in some of those libraries, but I couldn't verify that.