Setting Up Public Hosting

Public Hosting serves the contents of a folder over a public web URL. Use it to publish documents, forms, embedded assets, web applications, or other content you want available without a full Files.com login. Configure the URL, access controls, index listings, force-download behavior, and CORS headers per folder.

Enabling Public Hosting (Web Hosting) on Your Site

Public Hosting is configured per folder, through that folder's settings. You must be a site administrator or have admin rights on the folder.

When you activate Public Hosting (Web Hosting) mode for a folder, you specify the URL in the Serve files and sub-folders publicly at the following URL setting. The value can be anything that does not contain reserved, unsafe, or excluded characters as defined by RFC 1738. Space characters are allowed and are handled by most web browsers, but they are encoded in the URL. The value must also be unique among your publicly served folders; you cannot save a value that duplicates another Public Hosting folder setting.

Public Hosting works well for making files broadly available, but it is not a CDN. For large amounts of static content such as images and video, deploy a CDN in front of Files.com Public Hosting to optimize delivery for those scenarios.

Custom Domains

Attach a Custom Domain with the Destination of Publicly Served Folder to serve the folder from your own domain instead of the default [subdomain].hosted-by-files.com, with no edge platform required. If you need more control over the served URL, like rewrite rules that route across multiple domains or regions, pair Public Hosting with an edge platform instead.

URL Keys

The right URL value for your folder depends on what the public site is for. If the contents are intended to be freely available or to serve assets embedded in one of your websites, choose a friendly, descriptive URL that reflects the contents, such as forms.

If the contents are intended to be publicly reachable but hard to find without direct communication from your team, take a security-by-obscurity approach with a URL that resembles a token, such as sh4g7f3gf9xz39h-3hgtr4d or any link no one could reasonably guess without being given it directly.

For folders protected by a password or site login, a descriptive URL is appropriate because authentication controls access. If you also enable CORS, name the trusted websites in the folder's allowed-origins list before relying on that access gate. With an empty list, another website that knows the URL can read the content through an authenticated visitor. An unguessable URL does not replace an allowed-origins list.

How to Calculate File URLs

Customers sometimes need to list every URL for the files in a Public Hosting folder, such as when designing a data feed for an automated system.

By default, each hosting URL looks like this:

https://subdomain.hosted-by-files.com/key/relative/path/to/filename.ext

The URL breaks down into the following parts:

1. The protocol prefix, always https://.
2. Your custom subdomain.
3. The public hosting domain, hosted-by-files.com by default.
4. The key assigned to the hosted folder.
5. Any subfolders within your hosted folder. If your file is directly in the hosted folder, skip this.
6. Your file's name and extension.

Combine those parts without spaces. Any character in a folder or file name that is not a letter or number needs to be URL-encoded. For example, a space character in a file or folder name is encoded as %20. This is known as percent-encoding.

URLs with Custom Domains

When using a Custom Domain for Public Hosting, the URL for any file becomes:

https://your custom domain/key/relative/path/to/filename.ext

The URL breaks down into the following parts:

1. The protocol prefix, always https://.
2. The Custom Domain you've assigned.
3. The key assigned to the hosted folder.
4. Any subfolders within your hosted folder. If your file is directly in the hosted folder, skip this.
5. Your file's name and extension.

Combine those parts without spaces. Any character in a folder or file name that is not a letter or number needs to be URL-encoded. For example, a space character in a file or folder name is encoded as %20. This is known as percent-encoding.

Including Passwords in Calculated URLs

If you have enabled Password Protection for your hosted folder, you can create URLs that include the username and password. This is useful when non-interactive systems such as curl need to access a password-protected item.

To embed a password into your calculated URL, insert username:password@ immediately after https:// in your URL.

For your default public hosting domain, this will translate to:

https://username:password@subdomain.hosted-by-files.com/key/path/to/filename.ext

If you're using a Custom Domain for public hosting, your URL looks like:

https://username:password@your custom domain/key/relative/path/to/filename.ext

If your password contains characters other than letters and numbers, the password must be percent-encoded. Do not encode the colon (:) or the at-sign (@) that separate the credentials from the rest of the URL. As with the calculated URLs above, an attached Custom Domain replaces the subdomain and hosted-by-files.com portion.

Index Pages

Enable Index Pages on a Public Hosted folder to show public listings of the folder contents, including subfolders. This is useful when visitors don't always know the full path to the files they need, or when the folder does not contain an HTML document with a table of links.

When index pages are not enabled, only direct links to files within the folder or its subfolders work. Any attempt to access a folder directly through the public hosting link fails. If you add an HTML file with your own custom index listing, it is served only when visitors request that file directly, not when they request the folder.

Password Protection

You can secure a Public Hosted folder with a single username and password, collected through HTTP Basic authentication. The visitor sees a popup dialog in the browser. You can also include the username and password directly in the URL for use with curl and other non-interactive tools.

Password protection uses a single username and password for the entire folder, shared by everyone who accesses the public URL. To give different people their own credentials, create them as full users on your site instead.

Your site's Password restrictions rules apply to public hosting passwords by default. Site administrators can disable this with the Apply password rules to shares, inboxes, and publicly served folders setting.

Requiring Site Login

A Publicly Served Folder can require visitors to sign in to your Files.com site before any content is served. When this is enabled, a visitor who is not signed in is redirected to your site's login page. After completing authentication (through password, SSO, or two-factor authentication, whichever your site is configured to use), the visitor is returned to the originally requested content automatically.

This makes Public Hosting practical for internal audiences like employees, contractors, and partners who already have accounts on your Files.com site. Internal runbooks, team dashboards, training materials, compliance documents, and partner-facing resources can all be served this way, accessible to your site's users without being exposed to the open internet.

This gate is a site-membership check. Any active user registered on your Files.com site can view the content after signing in. It does not enforce per-folder file permissions for the underlying hosted path.

Because your Files.com site login already supports SSO, two-factor authentication, and your existing user provisioning workflows, site login gating requires no separate identity system. Users who are already onboarded to your site gain access automatically; removing a user's account revokes access immediately.

Non-browser requests that do not present a valid session receive a 401 response rather than a redirect.

Both site login and password protection can be active on the same folder. When both are configured, a visitor must pass both to reach the content.

Default Download Behavior

By default, Public Hosting does not set a Content-Disposition header on hosted files. When someone opens a publicly shared link, the browser decides how to handle the file based on its default behavior and the file's MIME type.

Files that usually open directly in the browser include images (.jpg, .png, .gif), text files (.txt, .xml, .json), and PDFs (.pdf). Audio and video files (.aac, .mp3, .mp4, .wav, and similar) usually open in the browser, though whether they start playing automatically depends on the browser.

Files that require an external application, such as .zip, .xlsx, .docx, and .exe, are usually downloaded because most browsers do not render them directly. JavaScript files (.js) are treated as text and displayed, not executed.

Because Files.com does not override the browser's default behavior with a Content-Disposition: attachment header, files open or download based on how your browser handles each file type.

To download a file that would normally open in the browser, use the "Save as" command after it opens. Right-clicking a link in most browsers gives you a context menu with a download option.

Force Download Option

To make files always download rather than open in the browser, enable the Force download of files setting on the Public Hosting folder. Files.com then applies a Content-Disposition: attachment header to every file, instructing the browser to download instead of opening.

CORS Header to Enable Cross-Domain Sharing

The Include Cross-Origin Resource Sharing (CORS) Headers setting lets JavaScript on other websites read the folder's files and enabled index listings. It is off by default. Enable it when another website needs to fetch hosted content, such as a data file used by a web application. CORS controls whether browsers let scripts read cross-origin responses; it is not a general restriction on linking to or embedding content, and it does not replace authentication.

For example, imagine you have a fundraising campaign, and you want your corporate site to reflect its current status. Your fundraising partners upload a text file each day containing anonymized donation data to a Public Hosting folder on your Files.com site. Your corporate site uses JavaScript to fetch the data from the Public Hosting URL, parse the contents, and display the current total dynamically. The number on the corporate page updates without manual editing.

Configure the folder's allowed-origins list (cors_allowed_origins in the API) to name the websites that may read its content. Each entry is an exact HTTP or HTTPS origin: a protocol, hostname, and port, such as https://www.example.com or https://reports.example.com:8443. Do not include paths or wildcards. In the example above, the list would contain your corporate website's origin. An omitted or empty list allows any origin. The list applies only when CORS is enabled.

When CORS is enabled and the requesting origin is allowed, hosted content responses include these headers:

With a nonempty allowed-origins list, a missing, invalid, or nonmatching origin receives no Access-Control-* headers; Vary: Origin remains. This prevents browser scripts on unlisted origins from reading the response. It does not reject an otherwise authorized request or prevent direct downloads and non-browser access. With CORS disabled, the setting adds none of the headers above.

For content intended to be freely available to everyone, allowing cross-origin reads does not expose private content. Content protected by a password or site login needs a narrower audience. If another website does not need to read the content, leave CORS off.

With either access gate enabled, reflecting the origin together with Access-Control-Allow-Credentials: true permits credentialed cross-origin reads. If the allowed-origins list is empty, script on any website that knows the URL can read the folder's content through a visitor who has already authenticated, when the browser sends that visitor's credentials. The script does not need to know the visitor's password. Enabled index listings also reveal filenames, so the website does not need to know each file's URL in advance. Do not enable unrestricted CORS on a gated folder whose content should remain private; name only the origins you trust to receive it.

Disabling Public Hosting (Web Hosting) on a Folder

A site administrator or a user with admin rights to the folder can disable Public Hosting at any time. As soon as the setting is updated, the files are no longer accessible at the previous URL.