My designer sent me a folder of files. How do I actually put it online?

This page may contain affiliate links from which Blur Studio earns commissions.

This is one of the most common small handoffs that goes nowhere: a designer or a freelancer finishes a site and sends you a ZIP file or a folder, and nobody tells you what to do with it. The files are done. They just aren't anywhere the public can reach them yet, and most hosting setups assume you already know words like "FTP" or "DNS record."

The fastest real option: drag and drop

Netlify Drop is built exactly for this moment. You open the page, drag your folder onto it, and the site is live at a netlify.app address within seconds. No sign-up screen stands between you and seeing the site work. Netlify's own documentation is explicit that no account is required to publish that first deploy, which matters if you just want to confirm the files actually work before committing to anything.

The catch, and it's a real one: that first deploy without an account expires. If you want the site to stay up, keep your own domain, or come back and update it later, you create a free Netlify account and claim the site, which takes under a minute and costs nothing.

Step by step: how to publish the folder

1. Unzip the folder if it arrived compressed. You need the actual folder with an index.html file at the top level, not a ZIP containing it.
2. Go to Netlify Drop and drag the folder onto the drop zone. Don't select and upload individual files one at a time; drag the whole folder in one motion.
3. Wait for the upload to finish. For a typical small site (a handful of pages, some images), this takes seconds to low minutes depending on image file sizes.
4. Click through to the live URL and check every page, not just the homepage. A missing image or broken link usually means a file path issue in how the designer built the folder, not something Netlify did wrong.
5. Create a free account to keep the site. Without this step, the deploy is temporary. With it, you can rename the site, connect a custom domain, and come back to update it later.
6. If you have your own domain, point it at the site. Netlify's own docs walk through adding DNS records or using Netlify DNS directly; either way this is a one-time setup, not something you redo per update.

One practical tip that saves a round trip: before you drag the folder in, open index.html in a browser locally first. If images are broken or links go nowhere on your own computer, they'll be broken online too, and it's faster to catch that before you've already shared the link with anyone.

What this actually costs

Netlify's Free plan includes 300 credits a month, and a production deploy costs 15 credits, so you could redeploy a site roughly 20 times in a month and still be on the free tier, which covers almost any non-technical business putting up a brochure site, a landing page, or a one-off campaign microsite. Bandwidth, compute and requests all draw from the same credit pool (roughly 20 credits per GB of bandwidth, 10 credits per GB-hour of compute, 2 credits per 10,000 requests), so a low-traffic static site essentially never touches the limit. If you do grow into real traffic or need more builds, Personal is $9 a month for 1,000 credits and Pro is $20 a month for 3,000 credits with unlimited team members, but most folder-handoff sites like this one never need to upgrade.

The alternatives, and when they make more sense

Cloudflare Pages does essentially the same drag-and-drop-or-connect-a-repo job, with Cloudflare's own CDN underneath it. If you're already deep in Cloudflare for DNS or security, staying in one dashboard has some appeal, though the actual publishing experience is comparable.

GitHub Pages is free and fine if the files are already in a GitHub repository and you're comfortable with Git, but it adds a learning curve a drag-and-drop deploy skips entirely, and it's a worse fit if "my designer sent me a folder" is literally your starting point.

Your existing web host via FTP works if you already pay for hosting somewhere and don't want a second service. It's usually slower to set up the first time (an FTP client, server credentials, folder structure conventions) and gives you none of what you'd get later from a proper deploy pipeline (previews, instant rollbacks, HTTPS by default).

When to skip this and use something else

If the site needs logins, a shopping cart, a booking system, or frequent content edits from non-technical staff, a static file drop is the wrong tool regardless of how it's hosted. You'd be re-uploading the whole folder every time someone wants to change a sentence. A site builder with a visual editor, or a proper CMS, is the better fit once editing is a recurring job rather than a one-time publish.

A worked example: a community group's event page

Say a volunteer coordinator for a local nonprofit gets a one-page event site built by a friend who does design on the side: a date, a location, a sign-up form that emails submissions to an inbox, and a short description of what to bring. The friend hands over a folder and moves on to other work. The coordinator has no budget for hosting and no interest in learning a dashboard, they just need the page live before the event is three weeks out. This is the exact case Netlify Drop is built for: drag the folder in, get a working link in under a minute, and paste that link into a community Facebook group and a few text threads the same afternoon. The only thing worth double-checking before sharing it widely is that the sign-up form actually sends somewhere real, since a static-file deploy doesn't run server-side code on its own, so a plain HTML form needs a service like Netlify Forms, Formspree, or a simple mailto link behind the submit button rather than assuming a bare form just works once it's online.

If the same coordinator needs the page again next year with a new date and a different venue, claiming the site with a free account the first time means next year's update is just editing the folder locally and dragging it back in, not starting from zero with a new unclaimed link that nobody's old bookmark points to.

Common mistakes with a first deploy

• Sharing the link before claiming the site. An unclaimed deploy is meant as a quick preview, not a permanent address; if you're about to put the link on a flyer or send it to a mailing list, claim it with a free account first so it doesn't quietly expire later.
• Assuming a contact or sign-up form just works. A static deploy serves files, it doesn't run server-side logic. A plain HTML form with no form-handling service attached will often look fine but silently fail to deliver anything when someone submits it.
• Dragging in the wrong folder level. If index.html ends up nested one level too deep (a folder inside the folder you dragged), the site deploys but shows a blank page or a directory listing instead of your homepage.

How I'd approach this

For a one-off handoff like this, I tell people to just do the drag-and-drop themselves; it genuinely takes less time than explaining it would. Where I actually get involved is the next question that usually follows: "okay, it's live, now how do I change the headline without emailing the designer again?" If that's where you are, the honest options are a proper CMS on top of the same hosting, or a rebuild with real content-editing built in from the start. Get in touch if you want a second opinion on which one actually fits your situation before you commit either way.