My Image URLs Are Breaking When Deploying to Netlify

6 replies
Last updated: Apr 3, 2020
My image urls are breaking when deploying to netlify. Images are found and displayed properly in development on local host, but when I deploy the request gets broken (see attached image)
I'm using the imageUrlBuilder package to build the URLs. I'm sure the cause of this is something I'm missing.
AI Update

I can help you troubleshoot this image URL issue with Netlify deployment. This is a common problem that usually relates to how environment variables or client configuration is handled between local and production environments.

The most common causes when using @sanity/image-url are:

1. Environment Variables Not Set in Netlify

Your Sanity client configuration needs the correct projectId and dataset in production. Make sure you've added these as environment variables in your Netlify dashboard (Site settings → Environment variables):

SANITY_PROJECT_ID=your-project-id
SANITY_DATASET=production

Then ensure your client configuration is reading from these variables:

import { createClient } from '@sanity/client'

export const client = createClient({
  projectId: process.env.SANITY_PROJECT_ID || process.env.NEXT_PUBLIC_SANITY_PROJECT_ID,
  dataset: process.env.SANITY_DATASET || process.env.NEXT_PUBLIC_SANITY_DATASET,
  useCdn: true,
  apiVersion: '2024-01-01'
})

2. Client-Side vs Server-Side Environment Variables

If you're using a framework like Next.js, remember that client-side code needs variables prefixed with NEXT_PUBLIC_. If your imageUrlBuilder is running in the browser, use:

  • NEXT_PUBLIC_SANITY_PROJECT_ID
  • NEXT_PUBLIC_SANITY_DATASET

3. Build-Time vs Runtime Variables

Netlify needs to have these variables set before the build runs if they're being bundled into your code. Check that you've:

  • Set the environment variables in Netlify
  • Triggered a new deploy after setting them (old builds won't have the new variables)

4. Check Your Image Domain Configuration

According to the @sanity/image-url documentation, if you're using Next.js, ensure your next.config.js allows Sanity's CDN:

module.exports = {
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'cdn.sanity.io' }
    ]
  }
}

Quick Debug Steps:

  1. Console log your client configuration in production to verify the projectId and dataset are correct
  2. Check the Network tab in your browser to see the actual URL being requested
  3. Verify the URL structure matches: https://cdn.sanity.io/images/{projectId}/{dataset}/...

The broken request you're seeing is likely generating a malformed URL because the projectId or dataset is undefined in your production build. Setting the environment variables properly in Netlify should resolve this!

Hm. I haven’t seen this one before. The imageUrlBuilder relies on a properly configured sanity client. Perhaps there could be something unexpected going on with your client config in production vs. in development?
Looks like an
<
opening tag creeped into that request URL somehow (although it’s escaped). That’s strange though if it’s working in localhost. Are there any conditionals you’re using for development vs. production?
I have an .envs for dev and prod. This is a migration from another cms and I tried to set it up like the sanity/create gatsby example. There are conditionals for watchMode and overlayDrafts. In playing around with this I noticed that my netlify builds fail when
...clientConfig.sanity
is used in my gatsby-config.js so perhaps the problem is in the config file...
Have you added the relevant environment variables to Netlify? https://docs.netlify.com/configure-builds/environment-variables/#declare-variables
I think Netlify and Zeit have both stopped processing .env files and require you to add these variables/secrets separately.
Netlify's handling of the env variables was the issue. Thanks for pointing this out.
Cool! Glad you got it straightened out 🚀

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?