SVG import fails with "Invalid image, could not read metadata" error

16 replies
Last updated: Jan 28, 2026
Hey all. I tried exporting a dataset and reimporting it using sanity/cli and get the following error message during import:
o: Failed to upload image @ file:///private/var/folders/yy/n3wpcs896hg369pyrwjmtd8w0000gn/T/ef684c991e2f22d04628e302b9e7225d/sanity-import/production-export-2021-06-29t06-33-57-244z/images/2f2fe1cbd0563b3ce3ea79fcdf1549ed244b3993-120x40.svg:
Bad Request - Invalid image, could not read metadata
    at onResponse (~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:4206:533)
    at ~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:2736:279
    at ~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:2724:918
    at ~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:2724:1026
    at E (~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:2772:1332)
    at ~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:2772:2845
    at s.<anonymous> (~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:1320:100)
    at A (~/.nvm/versions/node/v14.16.0/lib/node_modules/@sanity/cli/bin/sanity-cli.js:1338:6029)
The file in question is an SVG file and (I assume) the importer is trying to read JPEG/PNG metadata. Maybe this has something to do with:
https://sanity-io-land.slack.com/archives/C9Z7RC3V1/p1624181782323300

This used to work without sanity/cli complaining about image metadata. Is there a solution to this? Thank you in advance.
AI Update

You're hitting an issue with SVG files during dataset import where the CLI is trying to extract metadata that doesn't exist in the same way for SVG files as it does for raster images (JPEG, PNG, etc.).

What's happening: Sanity's image asset pipeline does support SVG files - you can see in the image transformation documentation that SVG is a valid format and can even be converted to bitmap formats like PNG or JPG through the CDN. However, the import process attempts to read metadata (dimensions, color information, etc.) from uploaded assets, and SVG files as XML-based vector graphics don't contain this metadata in the same format as raster images.

Solutions to try:

  1. Use the --allow-failing-assets flag when importing:

    sanity dataset import production-export.tar.gz production --allow-failing-assets

    This tells the CLI to continue importing even when asset uploads fail, so your documents will import successfully and only the problematic SVG assets will be skipped. You can then manually re-upload the SVGs afterward.

  2. Consider using the file type instead of image type for SVGs: Going forward, if you frequently work with SVG files, you might want to use the file field type in your schema rather than image type:

    {
      name: 'logo',
      type: 'file',
      title: 'Logo (SVG)',
      options: {
        accept: '.svg'
      }
    }

    The file type doesn't attempt to extract image metadata, which avoids this issue entirely.

  3. Manual workaround for existing exports: If you need to import an existing export with SVGs:

    • Extract the tar.gz file
    • Remove the problematic SVG files from the images folder
    • Re-compress and import with the remaining assets
    • Manually re-upload SVGs after import completes
  4. Host SVGs externally: For critical SVG assets, you could store them in your codebase or a CDN and reference the URL in Sanity rather than uploading them as assets.

The Slack thread you referenced is likely discussing the same limitation with how the CLI import handles SVG metadata extraction. While Sanity's CDN and transformation pipeline fully support SVG files once they're uploaded, the import process has this metadata extraction step that can fail for SVGs.

The --allow-failing-assets flag is probably your quickest solution to get your import completed without losing your document data.

Show original thread
16 replies

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?