Has anyone else noticed that images generated by Gemini 2.0 Flash via the API come with a prominent pollinations.ai watermark? I’m using the experimental version (gemini-2.0-flash-exp) in Google AI Studio, and while the web interface at aistudio.google.com gives me clean images, the API outputs have this big watermark. Is there a way to generate images programmatically without it, or is this just how the API is set up for now?
Hi @Guy_Kingston, Welcome to the forum!!!
This is how the API is set up for. Please see this doc
Thanks.
Hi @Govind_Keshari, thanks for the reply and the warm welcome! I’ve reviewed the doc (Generate images | Gemini API | Google AI for Developers), but I’m still a bit confused and could use some clarification. The doc says all generated images have a SynthID watermark, and Google AI Studio images should also have a visible watermark. However, my experience is the opposite: in the Studio web interface (aistudio.google.com), I get clean images with no visible watermark, but API-generated images have a prominent pollinations.ai watermark. I understand from your reply that this is how the API is set up, but I’m surprised to see a third-party watermark (pollinations.ai) instead of a Google/Gemini one. My API response includes a URL pointing to image.pollinations.ai/prompt/… (see JSON below), which generates the image with the watermark. Here’s the script I’m using:
import google.generativeai as genai
import json
import os
api_key = os.getenv(“GEMINI_API_KEY”)
genai.configure(api_key=api_key)
model = genai.GenerativeModel(“gemini-2.0-flash-exp”)
prompt = “Generate a 50-word story with 1 image in a bright, whimsical cartoon style. A farmer with a red hat tends to 3 cows on a sunny farm with a yellow barn. Scene: the farmer milks a cow near the barn.”
response = model.generate_content(
prompt,
generation_config={
“response_mime_type”: “application/json”,
“response_schema”: {
“type”: “object”,
“properties”: {
“text”: {“type”: “string”},
“images”: {
“type”: “array”,
“items”: {
“type”: “object”,
“properties”: {“url”: {“type”: “string”}}
}
}
}
}
}
)
The JSON result shows the pollinations.ai URL, and the image has the watermark:
{“text”: “{\n "images": [\n {\n "url": "https://image.pollinations.ai/prompt/Bright%2C%20whimsical%20cartoon%20of%20a%20farmer%20with%20a%20red%20hat%20tending%20to%203%20cows%20on%20a%20sunny%20farm%20with%20a%20yellow%20barn.%20Scene%3A%20the%20farmer%20milks%20a%20cow%20near%20the%20barn.\”\n }\n ],\n "text": "Farmer Giles, hat bright red, whistled a tune. Bess, Daisy, and Buttercup mooed contentedly in the sunny field. Near the yellow barn, Giles milked Bess, the pail filling with creamy goodness. A happy life on the farm!"\n}", “image”: “No image generated”}
Here’s the generated image with the watermark: https://tinyurl.com/2s46hzzj
Is the API outsourcing image generation to Pollinations.ai, and that’s why the watermark appears? More importantly, is there a way to generate images via the API without this visible watermark, matching the clean output I get in Studio? I’d really like to use the API for programmatic generation without the pollinations.ai branding.
Thanks for any insights!
This is the image generated when I ran the same prompt in the web interface, rather than through the api.
I personally prefer the web interface image generation but, using Grok 3 to go through all the documentation, I haven’t found a way of getting the api to use the web interfaces generator rather than the 3rd party Pollinators one.
Hey @Guy_Kingston,
For AI Studio generated images, lower-right corner with star like shape is the watermark.
I don’t think we are using third-party watermark (pollinations.ai). I tried with SDK also, but it’s generating clean images for me. I am not sure why you are getting (pollinations.ai).
I can see from your code, you are using older SDK and i am little confused with your generation_config. Can you please try this notebook once and let see if you are getting the same issue.
Thanks.
I’ve encountered the exact same issue with those mysterious Pollination AI watermarks. Since the image is returned as a regular URL instead of base64 encoding stated in the API docs, we can conclude that it wasn’t generated by the internal image generator. The most reasonable explanation is that the LLM “forgot” it can generate images and instead output a URL to an external image generation service that happened to be present in its training data.
At least that’s what happened in my case.