Site.json config file Last updated: 28. Sep 2026

The "Content-Security-Policy" header is designed to prevent Cross-Site Scripting (XSS) and data injection attacks. It allows web administrators to control which resources can be loaded and executed, thus enhancing the website's security.

Docly™ recommendation: Content-Security-Policy: default-src 'self';

This default setting restricts all content types to load only from the origin of the served document, implementing a strong same-origin policy.

The "X-Frame-Options" HTTP header is used to control whether a browser should allow a webpage to be rendered in a <frame>, <iframe>, <embed>, or <object>. Its main function is to protect against 'clickjacking' attacks, where a malicious site tricks a user into clicking something different from what the user perceives, potentially revealing confidential information or taking control of their account.

Docly™ recommendation: X-Frame-Options: SAMEORIGIN

This setting ensures that pages can only be displayed in frames or iframes that are from the same origin as the page itself. It's a widely supported and effective measure for protecting against clickjacking attacks.

The "X-Content-Type-Options" HTTP header is used to instruct the browser to stop automatically detecting and interpreting the content type of the resources it loads. This is particularly important for preventing MIME type sniffing vulnerabilities.

Docly™ default: X-Content-Type-Options: nosniff

This default value is universally applicable and is crucial for enhancing security by instructing the browser to strictly follow the declared content type in the MIME headers, thus preventing MIME type sniffing attacks.

The "Strict-Transport-Security" (HSTS) HTTP header is used to enforce secure connections to the server. Its primary function is to tell browsers that they should only interact with the server using secure HTTPS connections and not via the insecure HTTP protocol. This is a critical security measure for preventing "man-in-the-middle" attacks, where an attacker could intercept or alter the communication between the user and the website if transmitted over an unencrypted HTTP connection.

Docly™ recommendation: Strict-Transport-Security: max-age=31536000;

The "Referrer-Policy" HTTP header controls how much referrer information (the URL of the referring page) should be included with requests. This header is essential for privacy and security, as it governs the amount of information sent to the server when a user navigates from one page to another. Proper configuration can help prevent leakage of sensitive information through URLs.

Docly™ recommendation: Referrer-Policy: no-referrer-when-downgrade

This setting ensures that the full URL of the referring document is sent to the destination when the protocol security level is the same (HTTPS to HTTPS) or lower (HTTPS to HTTP). However, if the protocol security level is downgraded (from HTTPS to HTTP), it will not send any referrer information, thus preventing potential data leakage in unsecured environments.

The "Permissions-Policy" HTTP header (formerly known as "Feature Policy") is a mechanism that allows website administrators to control which browser features and APIs can be used in the browser. This header can enable or disable powerful features like geolocation, camera, microphone access, and more, within the site's own pages and for iframes.

This header is instrumental in enhancing security and privacy by restricting features that could be exploited by malicious content. For example, it can prevent third-party content embedded in iframes from accessing sensitive device features or user data without explicit permission.

By specifying the allowed features and the contexts in which they can be used, the Permissions-Policy header provides granular control over the execution environment of the web content, thereby contributing to a more secure and user-centric web experience.

Docly™ recommendation: Permissions-Policy: geolocation=(self), microphone=(), camera=()

quality sets the encoder quality used when Docly re-encodes a scaled image. It applies to the lossy formats — JPEG, WebP and AVIF. PNG is lossless, so quality is ignored there.

Write it either as a single number that covers every format, or as an object with a value per format:

Lookup order: the key for the format being written → the plain number or the default key → the built-in default. jpg is accepted as an alias for jpeg.

Built-in defaults: JPEG 85, WebP 78, AVIF 50. The AVIF scale is not comparable to JPEG/WebP — 50 gives roughly the same perceived quality as JPEG 85 at a much smaller file size.

Quality can never be set from a URL. This is the same ownership model as allowedSizes: an arbitrary quality in the URL would mean one cache entry per (size × quality), so any visitor could grow the cache without limit.

Invalid values are ignored rather than fatal. A non-number or a value of 0 or less falls through to the next level; anything above 100 is clamped to 100. A typo in site.json will not break image serving.

The quality fields are also editable in the Image sizes tab in the workspace folder properties, one field per format plus one for all other formats. An empty field means not set — the placeholder shows the built-in default that applies. Clearing every field removes the quality key from site.json.