# File Previews Browsing a project shouldn't mean opening a native app just to check you're looking at the right file. The web dashboard renders previews and thumbnails for common media directly, without downloading the whole file to your machine - the preview is generated server-side and you're sent a small image, not the 4 GB source. This is a dashboard and share-link feature. It doesn't change anything on the mounted drive: there, a file is just a file, and your own applications open it. ## Thumbnails in the file browser The Files view renders a thumbnail for any file type Swarmfile can rasterize, so a folder of renders or plates reads as a contact sheet rather than a list of names. Thumbnails are generated on the server and cached, so the first view of a file pays for generation and every view after is instant. Thumbnails are produced for: - **Images** - PNG, JPEG, GIF, WebP, BMP, TIFF, AVIF, and **Photoshop (`.psd`)** files. The PSD path flattens the composite, so you get the image a designer sees, not a layer dump. - **PDFs** - the first embedded JPEG image found in the file, not a true page render. This works well for the common case of a scanned or photo-heavy PDF, but a PDF with no embedded JPEG (pure vector graphics, text-only, or an embedded image in a different format) gets no thumbnail. Thumbnails use an embedded image; full first-page rendering isn't offered. (The full inline preview below is unaffected - it embeds the real PDF via the browser's own viewer, not this thumbnail path.) - **Video** - a poster frame (see below). - **Point clouds** - a top-down preview (see below). ## Inline preview Clicking a file opens an inline preview modal, without leaving the dashboard. Images, PDFs, and plain-text files render directly in the browser. Other types (a PSD, a video, a large TIFF) show their generated thumbnail instead of rendering the raw file inline - the browser can't display the source, but the poster tells you what it is. Rendering a source file inline is capped at 5 MiB - a browser tab isn't a useful place to view anything larger, and assembling a bigger file just to display it inline holds the server working for no real benefit. Past that size the modal falls back to the type's generated thumbnail or proxy instead (video proxies cover sources up to 16 MiB - see below); for a type with neither, it tells you to download the file. Downloading itself has no size limit. Anonymous visitors on a [public release page](https://swarmfile.com/docs/guides/publishing-releases) get a smaller inline cap of **256 KiB**, and only images and text render inline there - video and audio stream by range in the player instead (see [Public projects](https://swarmfile.com/docs/guides/public-projects-and-org-profiles)). ## Video posters and scrubbable proxies Video gets two levels of preview, both generated on the server rather than shipping the source anywhere: - **A poster frame** - a single still, shown as the file's thumbnail, for `.mp4`, `.mov`, `.m4v`, `.webm`, `.mkv`, `.avi`, `.wmv`, `.mpg`, and `.mpeg`. - **A scrubbable proxy** - a 720p H.264 MP4 the browser can play and scrub through, transcoded in the background from the full source and served with HTTP range requests. This lets a reviewer scrub a cut in the dashboard without pulling the master. A poster frame is extracted from the first 16 MiB of the source (`SWARMFILE_VIDEO_POSTER_HEAD_BYTES`), so it works even for a very large video - as long as the frame index sits near the start, which is the usual case for web-friendly MP4s. The scrubbable proxy needs the whole file, so it's generated only for sources up to 16 MiB; a larger video gets no proxy. Container previews are rate-limited, per project and again across the whole org (500 per project and 2,000 across the org per day by default). An organization's owner can raise or remove the caps under **Settings → Usage → Preview generation budgets** (`0` = no limit); a blank field keeps the default. Once a budget is used up, new video/point-cloud previews are refused with a typed `429` until the next day - the response says whether the project's or the organization's daily budget ran out and when it resets - but already-generated previews are cached and stay free to view. The dashboard flags the refusal with a "Previews are paused" banner rather than leaving a folder of empty thumbnails, and for an owner the banner links straight to those budget controls. Raw and camera-original formats (`.r3d`, `.braw`, `.mxf`, and similar) are **deliberately excluded** - they aren't reliably decodable without the right vendor codec, so rather than render a wrong or broken frame, Swarmfile shows the generic file icon and leaves them to a native app. ## Point-cloud previews `.las` and `.laz` point clouds get a rendered top-down preview, so a folder of LiDAR or photogrammetry tiles is browsable by eye instead of by filename. Like video, this is generated and cached server-side from the source. `.e57` and `.ply` are **not previewed** in this version - `.e57` needs a plugin and `.ply` lacks the georeferencing the top-down render depends on. The source cap for a point-cloud preview is 32 MiB. ## Previews in share links A share link carries the same inline preview for images, PDFs, and text, so an external reviewer with no account can see the shared item in their browser. See [Sharing & Collaboration](https://swarmfile.com/docs/guides/sharing-and-collaboration) for how share links work, and [Working with Files](https://swarmfile.com/docs/guides/working-with-files) for the mount side. ## What isn't previewed Limits, so you don't go looking for something that isn't there: - **End-to-end-encrypted content has no server-side preview.** Previews are generated on the server, and for an E2E project the server cannot decrypt the file - so E2E files show a generic icon, not a thumbnail or proxy. This is the deliberate trade of the E2E tier; see [Security](https://swarmfile.com/docs/admin/security). - **CAD/BIM files (DWG, RVT) show a generic icon; native design-file rendering isn't offered.** Image, PDF, PSD, video, and point-cloud previews are live. - **Caching is content-addressed.** Editing a file changes its content id, so its preview regenerates on the next view rather than serving a stale one - the first view after an edit pays for generation again.