What Is the `www` and `public_html` Directory in Your Hosting Account?

The `public_html` directory is the document root of your website — the server-side folder from which your web server (Apache, Nginx, LiteSpeed) reads and serves all publicly accessible files when a visitor loads your domain. The `www` directory, in most shared and cPanel-based environments, is simply a symbolic link (symlink) pointing to `public_html`, existing for historical compatibility rather than as an independent storage location.

Understanding this distinction is not cosmetic. Misplacing files outside `public_html`, misconfiguring the document root, or misunderstanding the symlink relationship can result in broken deployments, 403 Forbidden errors, or unintentional public exposure of sensitive configuration files.

The Role of `public_html` as the Document Root

When an HTTP request reaches your server, the web server daemon consults its configuration to determine which directory maps to the requested domain. That directory is called the document root. On virtually all shared hosting environments and most VPS Hosting configurations running cPanel or similar control panels, that document root is `public_html`.

The absolute path on a typical cPanel server looks like this:

“`

/home/username/public_html/

“`

Any file placed inside this directory becomes publicly reachable via your domain. The mapping is direct:

That last row is critical. Files placed above `public_html` in the directory tree — in `/home/username/` directly — are invisible to the web server and cannot be fetched via HTTP. This is the correct location for sensitive files such as database credentials, `.env` files, and API keys that your application reads at runtime but must never be served publicly.

Default Index Files and Directory Resolution

When a visitor requests a directory URL (e.g., `https://example.com/`), the web server looks for a default index file in that directory. The standard resolution order in Apache's `DirectoryIndex` directive is typically:

“`

index.html > index.htm > index.php > index.cgi

“`

If none of these files exist and directory listing is not explicitly disabled, the server may return a 403 Forbidden or expose a directory listing — a significant security risk. Always ensure either a valid index file exists or `Options -Indexes` is set in your `.htaccess`.

What the `www` Directory Actually Is

The `www` directory is a POSIX symbolic link, not a real directory with its own inode and storage allocation. You can verify this on any Linux-based server:

“`bash

ls -la ~/

“`

The output will show something like:

“`

lrwxrwxrwx 1 user user 10 Jan 15 09:22 www -> public_html

drwxr-xr-x 12 user user 4096 Jan 15 09:22 public_html

“`

The `l` at the start of the permissions string and the `-> public_html` arrow confirm it is a symlink. This means:

• `www` and `public_html` share exactly the same inode data
• Writing a file to `~/www/contact.html` is identical to writing it to `~/public_html/contact.html`
• Deleting `www` does not delete `public_html` or any of its contents
• Recreating the symlink is trivial: `ln -s ~/public_html ~/www`

Why the `www` Symlink Exists

The `www` symlink is a legacy artifact with practical roots. In early Unix-based hosting environments, the convention was to store web content in a directory literally named `www` — mirroring the `www.` subdomain prefix that became ubiquitous in the 1990s. As cPanel standardized `public_html` as the document root name, the `www` symlink was retained to avoid breaking:

• Older deployment scripts hardcoded to write to `~/www/`
• FTP clients and file managers that expected a `www` folder
• Documentation and tutorials referencing `www` as the upload target

For all practical purposes in a modern environment, you should treat `public_html` as the canonical location and ignore `www` entirely.

`public_html` vs `www`: Direct Comparison

Directory Structure Inside `public_html`

A well-organized `public_html` directory separates concerns clearly. Here is a production-realistic structure for a PHP-based site or WordPress installation:

“`

public_html/

├── index.php

├── .htaccess

├── wp-config.php ← WordPress config (ideally moved one level up)

├── wp-content/

│ ├── themes/

│ ├── plugins/

│ └── uploads/

├── assets/

│ ├── css/

│ ├── js/

│ └── images/

└── sitemap.xml

“`

Critical security note: `wp-config.php` contains database credentials. WordPress supports placing this file one directory above `public_html` (`/home/username/wp-config.php`), where it is unreachable via HTTP but still readable by PHP. This is a hardening best practice that many administrators overlook.

How Subdomains and Add-on Domains Extend This Structure

When you create a subdomain or add-on domain through VPS Control Panels or cPanel, the hosting system creates a new document root — either inside `public_html` or as a parallel directory at the same level.

Subdomain Document Roots

“`

/home/username/public_html/blog/ → blog.example.com

/home/username/public_html/shop/ → shop.example.com

“`

Or, in some cPanel configurations:

“`

/home/username/blog.example.com/ → blog.example.com

“`

Add-on Domain Document Roots

“`

/home/username/public_html/newdomain/ → newdomain.com

“`

Or as a top-level sibling:

“`

/home/username/newdomain.com/ → newdomain.com

“`

The exact path depends on your hosting panel configuration. Always verify the document root in cPanel under Domains > Subdomains or Addon Domains to avoid uploading files to the wrong location.

Behavior Differences Across Hosting Environments

Shared Hosting (cPanel)

On Shared Web Hosting with cPanel, the structure is standardized:

• Document root: `/home/username/public_html/`
• `www` symlink: present by default
• Apache with `.htaccess` support: enabled
• Multiple domains: each gets its own subdirectory or parallel folder

VPS and Dedicated Servers

On a Dedicated Server or self-managed VPS, the document root is entirely administrator-defined in the web server configuration. Common conventions:

Apache Virtual Host (`/etc/apache2/sites-available/example.com.conf`):

“`apache

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

DocumentRoot /var/www/example.com/public_html

</VirtualHost>

“`

Nginx Server Block (`/etc/nginx/sites-available/example.com`):

“`nginx

server {

listen 80;

server_name example.com www.example.com;

root /var/www/example.com/public_html;

index index.php index.html;

}

“`

On these environments, `public_html` is a naming convention, not a technical requirement. The document root can be named anything — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — as long as the web server configuration points to it. The `www` symlink typically does not exist unless you create it manually.

cPanel VPS

A VPS with cPanel combines the flexibility of a VPS with the standardized `public_html` structure of shared hosting, making it the most common environment where both `www` and `public_html` coexist exactly as described in this article.

File Permissions: A Frequently Overlooked Requirement

Incorrect permissions are one of the most common causes of 403 Forbidden errors and failed deployments. The standard permission model for web-accessible files:

Set permissions recursively with:

“`bash

find ~/public_html -type d -exec chmod 755 {} ;

find ~/public_html -type f -exec chmod 644 {} ;

“`

Never set `777` on any file or directory in a production environment. This grants write access to all system users and is a direct vector for server compromise.

SSL, HTTPS, and the Document Root

When you install an SSL Certificate on your domain, the certificate binds to the domain name, not to a specific directory. However, the HTTPS virtual host configuration must point to the same `public_html` document root as the HTTP configuration. A mismatch — where HTTP serves from one directory and HTTPS from another — produces inconsistent behavior that is notoriously difficult to diagnose.

If you use Let's Encrypt via Certbot, the ACME challenge verification process places temporary files in `public_html/.well-known/acme-challenge/`. Ensure this path is not blocked by `.htaccess` rules or Nginx `location` blocks that deny access to hidden directories (those starting with `.`).

Practical Key-Takeaway Checklist

Before uploading your site:

• Confirm the exact document root path in your hosting panel — do not assume it is always `/home/username/public_html/`
• Verify `www` is a symlink, not a separate directory, to avoid duplicate file management
• Move sensitive configuration files (`.env`, database credentials) above `public_html`

During deployment:

• Set directory permissions to `755` and file permissions to `644`
• Ensure an `index.html` or `index.php` exists at the document root to prevent directory listing
• Disable `Options Indexes` in `.htaccess` as a defense-in-depth measure

For multi-domain setups:

• Confirm the document root for each subdomain and add-on domain individually
• Do not assume all domains share the same `public_html`

On VPS and dedicated environments:

• Define the document root explicitly in your virtual host or server block configuration
• The `www` symlink does not exist by default — create it only if legacy scripts require it
• Restart the web server after any configuration change: `systemctl reload apache2` or `systemctl reload nginx`

For security hardening:

• Never store API keys, `.env` files, or database configs inside `public_html`
• Audit `public_html` periodically for unexpected files, particularly in `uploads/` directories
• Ensure your SSL virtual host points to the same document root as the HTTP configuration

Frequently Asked Questions

What happens if I delete the `www` directory?

If `www` is a symbolic link (which it is in virtually all cPanel environments), deleting it has no effect on your website or its files. Your site continues to function normally because the actual content lives in `public_html`. You can recreate the symlink at any time with `ln -s ~/public_html ~/www`.

Can I rename `public_html` to something else?

On shared hosting, no — the control panel is hardcoded to use `public_html` as the document root. On a self-managed VPS or dedicated server, you can name the document root anything you want, provided you update the web server configuration (`DocumentRoot` in Apache, `root` in Nginx) to match.

Why am I getting a 403 Forbidden error even though my files are in `public_html`?

The most common causes are incorrect file permissions (files need at least `644`, directories need `755`), a missing index file with directory listing disabled, or an `.htaccess` rule blocking access. Check the web server error log (`/var/log/apache2/error.log` or `/var/log/nginx/error.log`) for the specific reason.

Where should I store files that PHP needs to read but that should not be publicly accessible?

Place them in a directory above `public_html`, such as `/home/username/private/` or directly in `/home/username/`. PHP can read files anywhere on the filesystem that the web server user has permission to access, but the web server will not serve files outside the document root via HTTP.

Does the `www` subdomain work differently from the non-www domain at the server level?

No. Both `www.example.com` and `example.com` are resolved to the same document root through DNS configuration and virtual host settings. The `www` directory symlink on the filesystem is unrelated to the `www.` DNS subdomain — they are separate concepts that happen to share the same three letters.