n8n save image to Google Drive: How do you create a direct download URL?

You know that annoying moment when you generate an image with GPT-4o and it comes back as a blob of binary data? 🤔 Yeah. Now you need a public URL for it, and suddenly everyone’s telling you to set up an S3 bucket or a Cloudinary account.

There’s a much simpler way to save an image to Google Drive in n8n and get a working download link from it, using a tool you already have. 👇

I use this trick constantly in my own workflows. It’s not fancy. It won’t scale to a million images a day. But for most automation use cases? It’s more than good enough, and it takes like four nodes.

The Problem With AI-Generated Images in Automations

So here’s what happens. You call OpenAI’s image generation endpoint, whether that’s GPT-4o, DALL-E, whatever, and depending on how you configure the request it can give you back the image as a base64 encoded string or a temporary URL.

If you get base64, that’s not a file. That’s not a permanent URL. It’s just raw data sitting in your workflow.

“Typically it creates it in binary format and you need to store that somewhere to immediately download it again, right?” That’s the core issue.

And that’s the exact problem. The next step in your workflow, maybe it’s sending the image in a Slack message, embedding it in an email, passing it to another API, almost always needs a URL.

A publicly accessible URL that points to an actual file.

The “proper” solution is to spin up a storage service. AWS S3, Google Cloud Storage, Cloudinary, Imgur’s API. They all work. They’re also total overkill for a quick automation that generates a handful of images.

Why Google Drive Is the “Good Enough” Hack

“There’s actually a really easy way that you can just use Google Drive to do this.” That’s the shortcut.

I love this approach because it’s pragmatic. You already have a Google account. You already have Google Drive. The n8n Google Drive node is built-in and well-supported.

So why are we making this harder than it needs to be?

“It removes the necessity to create a new account on some other website and create another API call.” No new credentials, no extra vendor to maintain.

The Full Workflow, Node by Node

Here’s the actual n8n workflow I walk through in the video. It’s five nodes total, and the whole thing takes about 10 minutes to build from scratch.

Node 1: Generate the Image

This is a standard HTTP Request node (or the OpenAI node, depending on your preference) that hits the OpenAI images endpoint. You send your prompt, pick your size, and set the response format to b64_json so you get the image data back directly.

The key thing here, and this trips people up, is that you’re getting back a base64 string, not a file. It looks like a massive wall of random characters. That’s normal.

Node 2: Convert to File

This is where you turn that base64 string into an actual .jpg or .png file. In n8n, you’d use a Convert to File node (it used to be called “Move Binary Data” in older versions).

It takes the base64 data and converts it into binary that the next node can actually work with.

Without this step, you’re just trying to upload a text string to Google Drive. Which doesn’t work. I mean, it’ll upload something, just not an image.

Node 3: Upload to Google Drive

Now you use the n8n Google Drive node with the Upload operation. Point it at whatever folder you want (I usually create a dedicated “automation-images” folder to keep things tidy), connect your Google credentials, and let it rip.

The important output here is the file ID. Google Drive assigns every uploaded file a unique ID, and you’ll need that for both the next step and the final URL.

The node returns this automatically in its output JSON.

Node 4: Share the File (This Is the Step Everyone Misses)

This is the critical part. “The item that you just uploaded to Google Drive, it needs to change its permission to be accessible everywhere on the internet.” That permission change is what turns Drive into a usable host.

By default, files uploaded to Google Drive are private. Only your account can see them. If you try to build a URL right now, anyone who clicks it gets a “request access” page. Totally useless for automation.

You need a second Google Drive node set to the Share File operation. Here’s what you configure:

• File ID: Wire this from the output of your upload node
• Role: Reader
• Type: Anyone

This makes the file publicly readable. Anyone with the link can download it. No sign-in required.

You find this by adding a new Google Drive node and looking under the operations for the Share File option. It’s a little buried, honestly. “Share File” is easy to miss.

Node 5: Build the Direct Download URL

This is where things click. Most people know you can share Google Drive files with a link, but that link takes you to a preview page. It doesn’t give you the actual file.

That’s a problem when you need a URL that another API can download directly.

The URL format you need is:

https://drive.usercontent.google.com/download?id=YOUR_FILE_ID_HERE

In n8n, you’d construct that as an expression:

https://drive.usercontent.google.com/download?id={{ $json.id }}

(The exact expression path depends on your workflow structure. You might need a different JSON path depending on how you’ve named and connected your nodes.)

“So what you do is this is the variable of the File ID that you, and you get that when you upload the file. So, it’s pretty simple.” And yeah, it really is.

That URL will directly download the file. No preview page, no “open with Google Docs” nonsense. Just the raw image file.

Quick Reference: The URL Formats

Limitations You Should Know About

I’m not going to pretend this is a perfect solution. It’s a hack, and hacks have tradeoffs.

Google Drive has rate limits. If you’re generating hundreds of images per hour, you’ll hit API quotas. The Google Drive API allows roughly 20,000 queries per 100 seconds per project, but individual operations like uploads and permission changes eat up quota fast.

For a few dozen images a day? Totally fine. For a production system processing thousands? Look into proper object storage.

The URL format may not be officially documented by Google as a stable endpoint. The drive.usercontent.google.com domain works and has been working, but Google hasn’t published it as a guaranteed stable API endpoint.

Could they change it? Theoretically. It’s worth knowing you’re building on a pattern that could shift.

Public means public. There’s no access control beyond “anyone with the link.” The URLs aren’t easily guessable since file IDs are long random strings, but they’re not secret either.

Once shared, you can’t really control who accesses them. Assume it can leak.

Google may show a virus scan interstitial for larger files. For files over about 100MB, Google Drive can insert a confirmation page before the download completes. For typical AI-generated images (usually well under a few MB), this shouldn’t be an issue at all. Most images won’t trigger it.

For most n8n automation use cases, generating blog images, creating social media graphics, building prototypes, none of these limitations matter. But if you’re building something that needs to handle serious volume and be bulletproof, this isn’t the right approach.

Final Thoughts

The whole point of this workflow is that you don’t need another service. You’ve got Google Drive, you’ve got n8n, and with four or five nodes you’ve got a working pipeline from AI-generated binary data to a publicly accessible download URL.

The two pieces that make it work, changing the permissions programmatically and using the drive.usercontent.google.com URL format, are the parts most people don’t realize even exist.

Is this going to replace a proper CDN for a production app? No. But for building automations where you just need a public URL for an image so the next step in your workflow can pick it up? This is the fastest path I’ve found, and I keep coming back to it because it just works.