Can I Use My Own Images With an AI Website Builder?

Yes. You can attach an image in the chat as a visual reference for the build, and you can place your own photos on a page by giving their direct links. What an attachment does not do is upload the file: it guides the model, it does not become a hosted asset on your page.

That distinction is the whole answer, and almost every confused question about images in AI builders comes from missing it. Below is what each path actually does, where to keep your files so the links do not rot, and the honest limits.

What happens when you attach an image to the chat?

The attachment is sent to the model as a picture to look at. It is resized in the browser, then it rides along with your next message. The model reads it the way a designer reads a mood board: layout, palette, spacing, the general feel of the thing you pointed at.

That makes it useful for a specific class of instruction that is painful to write in words. "Make the hero section look like this" is one sentence with a screenshot attached, and several paragraphs without one. Same for "match this colour scheme" or "the card grid should sit like this one does".

What it is not is a file upload. The picture informs the build, it is not saved next to your project and it does not appear on the published page. If you attach a photo of your team and say "put this on the about page", you will get a page with a team section and a stock photo in it, because the model can see your picture but cannot serve it to visitors.

The practical rule: attach images to explain how it should look, use links to control what appears on the page.

How do you get your own photo onto a published page?

Give the direct link and say where it goes. A prompt like "use https://example.com/photos/storefront.jpg as the hero image, full width" is an ordinary edit, and the builder writes that URL into the page.

The link has to be direct, meaning it ends at the image file itself and opens a picture when you paste it into a browser address bar. A link to a Google Drive preview page, a Dropbox share page or an Instagram post is a link to a web page that shows an image, not to the image, and it will not render inside your site.

For several images at once, list them with their jobs rather than dropping them in a heap. "First product card: [link], caption Ceramic mug. Second: [link], caption Linen apron." Naming the slot next to each file is what keeps them from being shuffled.

An edit like this costs 3 credits and leaves the rest of the page alone. If you are placing a dozen photos, it is usually cheaper to list them all in one edit than to do twelve rounds of one photo each.

Where can you host images so the links keep working?

The image lives wherever you put it, and your page just points at it. This is normal for the web, and it means a dead host equals a broken picture. Here is how the common options compare.

Supabase is the path that stays inside the toolchain you are already connecting for data and sign-in, so it is the one we would suggest first if you have no host at all. The full setup is in connecting Supabase to an AI-built app.

What images does the builder use if you supply none?

Stock photography, chosen to fit the brief. A build for a bakery gets bakery-looking photos, a build for an accountant gets office-looking ones, and the page renders as a finished thing instead of grey boxes with "IMAGE" written in them.

This is deliberate, because an empty placeholder makes it impossible to judge whether the layout works. It is also temporary by design. Stock images are there so you can see the shape of the page, and swapping them for your real photos is one of the first edits most projects need.

Worth being blunt about the consequence: a site that ships with untouched stock photos looks like every other site that shipped with untouched stock photos. Your own pictures are the single cheapest way to stop a generated page from looking generic, which is the topic of do AI-built sites all look the same.

Which of your images actually earn their place?

Not all of them. The ones that change how a page reads, in rough order of return:

• The hero image. It sets the tone before a single word is read. Replace this one first.
• Product or work photos. On a shop or a portfolio these are the content, and stock cannot stand in for them.
• Faces. A real team photo does more for trust than any amount of copy about being trustworthy.
• The logo. Small, but it is the difference between "a site" and "your site".

Decorative section backgrounds are the ones to leave alone longest. They are the least noticed and the most likely to be restyled anyway as you keep editing.

How do you check the images actually load?

Test on the published address, not in the builder preview. Publishing puts the project on an address like your-project.zugo.run, and that is the context a visitor sees.

Every build is booted in a sandbox before it reaches you, and a build that fails to render is reported as a failure rather than handed over. That lowers the risk of opening a blank page, but it does not remove it, and it is a render check rather than an audit of every external link on the page. An image URL that has since gone dead is exactly the kind of thing that check will not catch for you.

So do the thirty second version yourself:

1. Open the published address in a browser you are not logged into anything with.
2. Look at every image slot, including the ones below the fold.
3. Open it on a phone, where a heavy photo shows its weight most obviously.
4. If a picture is missing, paste its link straight into the address bar. Nothing there means the link is the problem, not the build.

What are the limits worth knowing before you start?

Three, stated plainly.

There is no built-in media library. Your files are not stored in the project, so there is no gallery to browse and reuse from, and you keep track of your own links.

Attachments are references, and they are consumed by the message they ride with. Attach the same screenshot again for the next instruction if the next instruction needs it too.

The builder does not fix your source material. A 6 MB phone photo used as a full width hero will make the page slow, and no prompt turns that into a fast page. Resize and compress before you link, the same as you would on any site.

None of that is unique to AI builders, it is just how the web works, and it is the part that tools tend to leave out of the demo. If you would rather manage assets in a normal project structure, export the code to GitHub and keep going from there: the project is yours.

The quickest way to find out how your own photos land is to build the page and swap one image. Starter credits are free and need no card, which covers a build plus a few rounds of edits. Open the builder at zugo.dev, describe the page, then paste one real link and see it appear.