Error importing SVG file with invalid metadata in Sanity CLI

16 replies
Last updated: Jul 1, 2021
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.

I just tried the same procedure with 2.10.0 and 2.7.4 of the sanity/cli package and it seems like the error is not sanity/cli dependent but API specific, as the error message stays the same.
i see you’re uploading an svg but does this error for other common types like jpg or png?
Could you DM me the SVG in question?
user G
The error happens at 4% of "uploading assets", so I assume other files go through
Let me have a look at the file
Posted the SVG to
user Z
- didn't see anything wrong with the file, it opens just fine in OSX/preview. Out of all the attempts that stopped at a varying degree of completeness of the "uploading assets" stage, it always breaks with the same file
WebStorm complains about an illegal attribute on an xml property but that shouldn't affect imports, unless there is advanced magic happening on your side like SVG syntax verification?
There is some SVG sanitization which I believe is causing this. I'm trying to figure out if there's attributes that are considered "dangerous" in here somehow.
OK. "data-name" is considered illegal by WebStorm's parser
Yeah. I think it's the
<
/
>
in there that is throwing of our image processor
an empty closing tag like
</>
? I can't see one
or this:
<g
*id*="_Group_" *data-name*="<Group>"*>*
To be honest, I just grabbed that SVG and uploaded it 2 years ago when there was no sanitiser in place I think, hehe
The latter. And yeah, the sanitizer is a new addition to the pipeline, to prevent XSS and such. We're still trying to balance it in terms of how eager it is 😉
user B
We've deployed some changes that should make this go through now - can you verify?
user Z
Seems to do the trick. Thanks for looking into this!

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?