How to Upload a Website to a Web Server Using FTP

You have finished building your website and the files are ready on your computer. The next step is getting those files onto the web server so visitors can actually access the site.

FTP is one of the most established ways to do this. You connect to the hosting server, locate the directory that serves your website, and transfer your local files into it.

The process itself is straightforward, but uploading to the wrong directory, using an incorrect folder structure, or accidentally overwriting production files can cause problems. This guide walks through the process carefully.

What Do You Need Before Uploading a Website?

Before starting, make sure you have:

• Your website files on your computer
• A web-hosting account or server
• The server hostname
• Your FTP, FTPS or SFTP username
• Your password or other required authentication
• The correct port
• The remote directory where the website should be uploaded

Your hosting provider normally supplies the connection information. If you use a hosting control panel such as cPanel, the FTP account section can also show or let you create the required credentials.

Step 1: Prepare Your Website Files

Before connecting to the server, inspect the local folder containing your website.

For a simple website, it might look something like this:

my-website/
??? index.html
??? about.html
??? contact.html
??? assets/
?   ??? css/
?   ??? js/
?   ??? images/
??? favicon.ico

A PHP application might instead contain files such as:

my-website/
??? index.php
??? .htaccess
??? app/
??? public/
??? storage/
??? vendor/

The exact structure depends on the application. What matters is preserving the directory relationships expected by your website.

If a CSS file is located at assets/css/style.css locally, it should normally remain at that relative location when deployed unless your application is specifically configured otherwise.

Step 2: Find Your FTP or SFTP Credentials

You need connection credentials before an FTP client can communicate with the server.

A typical configuration includes:

Do not guess the protocol simply from the hostname. Use the connection method and port specified by your hosting provider.

If your server supports SFTP or FTPS, consider using an encrypted protocol rather than plain FTP. See our FTP vs SFTP vs FTPS comparison for the differences.

Step 3: Connect to the Web Server

Open your FTP client and enter the connection details provided by your host.

After authentication succeeds, you should be able to browse the server's remote filesystem.

If the server refuses the connection before you can log in, work through our FTP Connection Refused troubleshooting guide before changing deployment settings.

Do not start uploading immediately. First identify where the website actually belongs.

Step 4: Find the Website's Document Root

The document root is the server directory from which your website's public files are served.

Depending on your hosting environment, it might have a name such as:

• public_html
• www
• htdocs
• httpdocs
• public

Do not assume that one of these names is always correct. Different hosting platforms and applications use different structures.

For example, on many shared-hosting accounts the primary domain uses:

/public_html/

A subdomain or addon domain may use a completely different directory.

Uploading files successfully to the server does not mean they were uploaded to the correct location. If you put them outside the document root, the transfer can succeed while nothing changes on the website.

Step 5: Check What Is Already on the Server

Before replacing anything, inspect the existing remote files.

You may find:

• An existing website
• A default hosting page
• A previous version of your application
• Configuration files
• Server-generated directories

If you are updating an existing production website, create an appropriate backup before overwriting important files.

Pay particular attention to files such as .htaccess, environment/configuration files, uploaded user content and other server-specific data. Your local development copy may not be an appropriate replacement for them.

Step 6: Upload the Website Files

Once you have confirmed the correct remote directory, transfer the required files while preserving their relative folder structure.

For example, suppose your local project contains:

index.php
assets/css/app.css
assets/js/app.js
assets/images/logo.png

If these files belong directly in the document root, the remote structure should normally become:

/public_html/index.php
/public_html/assets/css/app.css
/public_html/assets/js/app.js
/public_html/assets/images/logo.png

The exact root path can differ, but the relative paths within the application remain important.

Do You Need to Upload the Entire Website Every Time?

No.

When publishing a website for the first time, you may need to transfer most or all deployable files. After that, uploading the entire project for every small update is often unnecessary.

If you changed only:

assets/css/app.css
app/Controllers/ProfileController.php
app/Views/profile/edit.php

you can deploy those specific files while preserving their paths instead of retransferring hundreds or thousands of unchanged files.

This is particularly useful for websites that are updated frequently.

Why Relative Paths Matter During Deployment

Imagine that you modified this local file:

app/Views/profile/edit.php

If your project root corresponds to the remote application root, the file needs to arrive at:

/remote-root/app/Views/profile/edit.php

Uploading it directly into:

/remote-root/edit.php

would lose the directory structure and would not update the intended application file.

This is why path-aware deployment is useful when you know exactly which project files changed.

Uploading Changed Website Files with BrowserFTP

BrowserFTP includes a path-based workflow designed for this type of deployment.

Instead of manually navigating through multiple local and remote folders for each changed file, you can select your local project directory and paste the relative paths of the files that changed.

For example:

public/assets/app.css
app/Controllers/AuthController.php
app/Views/auth/login.php

BrowserFTP can validate those paths against your selected local project and remote destination before they are queued for upload.

This approach is useful when a developer or coding tool already gives you a list of changed files.

Step 7: Verify the Uploaded Files

Do not assume that a completed transfer means the deployment is correct.

After uploading, verify:

• The expected files exist remotely
• The remote paths are correct
• File sizes look reasonable
• The website loads
• CSS and JavaScript assets load correctly
• Important pages still work
• Forms or application functions affected by the change still work

If you replaced cached frontend assets, you may also need to perform a hard refresh or otherwise account for browser, CDN or server caching before deciding that the upload failed.

Why Does the Website Still Show the Old Version?

If the upload completed but the website still appears unchanged, several explanations are possible.

1. You uploaded to the wrong directory

This is one of the first things to check. Confirm that the remote path actually belongs to the domain or subdomain you are viewing.

2. Browser caching

Your browser may still have an older CSS, JavaScript or page resource cached.

3. CDN or server caching

A CDN, reverse proxy, application cache or hosting cache may continue serving an older version.

4. The wrong file was replaced

Projects sometimes contain files with similar names in different directories. Verify the exact remote path.

5. The application generates or compiles assets

Some frameworks require a build, cache-clear or other deployment step in addition to transferring source files.

Why Does the Website Show a 403 Error After Uploading?

A 403 Forbidden response can indicate that the web server cannot access the required file or directory, but permissions are only one possible cause.

Check:

• File and directory permissions
• Ownership
• Server configuration
• .htaccess rules where applicable
• Whether the expected index file exists

For a deeper explanation of permission values, read FTP File Permissions Explained: CHMOD, 644, 755 and 777.

Why Does the Website Show a 404 Error?

A 404 Not Found after deployment can mean the requested file is missing, but dynamic applications can have additional causes.

Check that:

• The files were uploaded to the correct document root
• The expected directory structure was preserved
• The application's rewrite rules are present
• The URL is correct
• The application routes are configured correctly

What If FTP Says Permission Denied?

A permission error means you should diagnose the server-side restriction rather than repeatedly retrying the transfer.

Possible causes include incorrect ownership, insufficient directory permissions, account restrictions or an attempt to modify a protected location.

See How to Fix FTP and SFTP Permission Denied Errors for a structured troubleshooting process.

Should You Upload a Website as a ZIP File?

For large first-time deployments, uploading an archive and extracting it on the server can sometimes be more efficient than transferring thousands of small files individually.

But there are important considerations.

• The server or file manager must support extraction.
• You need enough storage for the archive and extracted files.
• You must verify the extraction destination.
• Existing files can still be overwritten.
• Archive contents must be trusted.

For incremental deployments involving only a handful of changed files, uploading those individual files is often simpler.

Be Careful with Configuration and Secret Files

A local project can contain files that should not be published or should not replace their production equivalents.

Depending on the application, examples can include:

• Local environment files
• Development configuration
• Database exports
• Debug logs
• Source-control metadata
• Local caches
• Development-only dependencies

Never assume that copying the entire local project directory to the web root is safe. Understand your application's deployment structure first.

A Safer Website Upload Checklist

1. Confirm the correct server and protocol.
2. Confirm the correct remote document root.
3. Back up important production files when appropriate.
4. Review which local files actually need deployment.
5. Preserve the required relative directory structure.
6. Do not overwrite production-specific configuration accidentally.
7. Upload the files.
8. Verify their remote paths.
9. Test the live website.
10. Check relevant logs if something fails.

FTP Is Only the Transport Layer

One important principle is that FTP does not understand your application.

It transfers files.

Your application determines which files belong on the server, your hosting configuration determines where they belong, and the web server determines how they are executed or served.

Once those responsibilities are clear, FTP deployment becomes much easier to reason about.

If you are new to browser-based FTP, continue with How to Use FTP in a Browser. If you are deciding which connection protocol to use, read FTP vs SFTP vs FTPS.

Common Questions Asked