Storage usage disclosure

Source interpretation and rasterization

Supported documents are interpreted on a server and their pages are rendered into pixel-based images. For a PDF, this can involve resolving fonts, drawing vector paths, decoding embedded images, applying clipping and transparency, and compositing the page at a configured resolution. Other supported formats may first be converted into a normalized document or image. The original upload is preserved; processing can retain a separate processing-source copy or converted intermediate as an additional stored object.

Multiple resolutions and tile grids

Processing can produce an overview plus higher-resolution page representations for closer inspection. Detailed levels are divided into independently encoded WebP image tiles, addressed by page, resolution level, column, and row. Tiles at the right and bottom edges can be smaller than the configured tile dimensions. Page metadata describes dimensions, scale factors, and grid sizes so a compatible viewer can place each tile correctly.

For an ordinary grid with raster width W, height H, and square tile edge T, the number of tiles at that level is ceil(W / T) × ceil(H / T). Doubling resolution along both axes creates four times the pixel area, with tile counts also affected by edge rounding. Keeping several resolution levels stores several representations of the same page. Overview levels may use a single image rather than the detailed tile grid.

Why this helps less powerful devices

In the cloud-tiled viewing path, expensive source interpretation and page rasterization happen on the server. The viewer decodes and composes prepared images, choosing a resolution appropriate to the zoom level and prioritizing visible areas. It can also preload overview, active-page, and nearby-page assets to support navigation. This reduces the amount of source-document rendering a device must perform locally, which can help devices with limited processing power or memory. The device still needs resources to transfer, decode, cache, and display the images. Cloud and local viewing paths differ by document format and viewer; this does not mean every device or document uses the same processing path.

Visual density and variable encoded size

Upload size is not a reliable predictor of the resulting viewing assets. A compact PDF may describe a large page using vector commands, reusable objects, and compressed images. Rasterization expands those instructions into a pixel grid. The final compressed tile sizes depend on page count, physical dimensions, rendering resolution, visual density, and how well the rendered pixels compress. Dense linework, fine text, photographs, gradients, and noisy scans can produce different output sizes from large areas of uniform color, even when the original uploads have similar byte counts.

Four times the pixel area does not guarantee four times the stored bytes: image encoding, content, and configured output settings also affect the result. There is no guaranteed processed-file size or fixed storage multiplier based solely on the uploaded file’s size.

Additional artifacts and retained generations

Alongside tiles, processing can retain page thumbnails, document metadata, a manifest describing generated assets, and OCR text with positional data when that processing is enabled and succeeds. These are separate stored objects with their own byte sizes. Outputs are associated with a particular source version and processing generation. New versions or reprocessing can create additional output sets; retained earlier sets continue to contribute to usage until removed through cleanup. The file-usage total includes the recorded sizes of retained workspace-scoped source, preview, derivative, and processing-artifact files.