PDF with selectable text on mobile, audio with waveform and lyrics, video with seek on encrypted storage, HEIC, SVG, STL 3D models, markdown with TOC — one preview pipeline, no plugin marketplace.
Cotton can represent photos, documents, audio, video, and model files in the same browser file surface. That matters for real libraries where media, work documents, scans, notes, recordings, and design files live together.
The preview story is backed by concrete file surfaces: image/SVG/HEIC rendering, PDF and text previews, audio waveform or cover-art thumbnails, synchronized lyrics, native video playback, on-demand HLS for legacy video, model thumbnails, share-page context, and cache-friendly delivery over Cotton-managed content.
Previews decide whether a self-hosted cloud feels like a product or a cold object bucket. Cotton treats the preview layer as part of the file workflow: browse, inspect, share, seek, and only download when that is actually the next step.
PDF previews are not just download buttons in disguise. On mobile, this matters most: Cotton can keep the document in the browser workflow, and selectable text can stay usable when the PDF source contains real text.
Audio previews first try embedded cover art, then fall back to generated waveform artwork. The player can also use sidecar text tracks such as LRC/SRT for synced lyrics without pretending the audio file is just a dead blob.
Video previews are generated through a controlled FFmpeg path that can read through range-capable streams. The goal is to show useful posters without turning every video into a giant temporary download.
Browser-native video can stream as the original file with Range support. Legacy video such as AVI/MKV can be opened through token-authorized HLS: Cotton builds playlists, transcodes short segments on demand from the chunked source stream, and caches segments briefly instead of preconverting the whole file.
Most everyday preview work stays close to the managed .NET runtime: image, SVG, HEIC, text, and PDF generation do not require turning the app into a pile of unrelated services. FFmpeg is kept for audio/video, and f3d is kept for model thumbnails.
Preview generation is part of normal product work, not an after-hours maintenance script. Cotton can prioritize preview jobs and use active-upload plus quiet-hour signals so heavier background work does not sabotage foreground transfers or make a home server noisy at the wrong time.
Previews also matter outside the account. A recipient opening a shared file should understand what they received before downloading it, especially for media, PDF, and model files.
Previews are stored by content identity, support cache-friendly responses, and expose encrypted preview hashes instead of raw storage keys.
Preview support is only credible when it respects the file type and security boundary. Some formats need safe generator support, and client-side encrypted folders must not be marketed as if server-side preview extraction can see plaintext everywhere.
Cotton previews make a real self-hosted library legible: documents remain readable, PDFs can stay selectable in the browser, audio gets a player with waveform or cover art, and media previews stay tied to the same chunked storage path.
On phones and tablets, PDF preview is more than convenience: when the source contains text, users can inspect and copy it in Cotton instead of bouncing into another app.
Cotton can extract embedded cover art, fall back to generated waveform artwork, play the file, and show time-synced lyrics from sidecar LRC/SRT text.
AVI/MKV-style files can get poster previews and HLS playback without preconverting the entire source. FFmpeg reads range-backed segments from Cotton storage as playback needs them.
Image, SVG, HEIC, text, and PDF preview paths keep the common daily cases close to the .NET runtime instead of turning every file type into glue code.
Preview jobs are product work, so the background scheduler can prioritize them while heavier maintenance knows when to delay or pace itself.
Previews are stored by content identity, but public URL material uses encrypted preview hashes and cache-friendly responses.
If users need to download every file just to understand what it is, the cloud failed at the browsing layer. Cotton treats previews as prioritized product work: generate the useful view, cache it by content, push readiness to active clients, and avoid making users leave the app for basic inspection.
Preview breadth depends on file type support and safe generator behavior. Client-side encrypted folders must keep their encryption boundary, so not every preview mode should be promised everywhere.
No. Photos are only one part of the preview surface. Cotton also covers PDF, text, audio, video, SVG, HEIC, and selected 3D model content.
Yes. That is the point of the mobile PDF preview story: phone and tablet users should be able to read and copy selectable text inside Cotton when the PDF source supports text, instead of switching viewers.
Cotton can fall back to generated waveform artwork. Audio playback can also use sidecar LRC or SRT text tracks for synced lyrics when those files are present.
Not necessarily. Browser-native formats stream directly. Legacy video can use on-demand HLS when Cotton can generate a preview/probe it: FFmpeg reads the seekable chunk stream and produces short playback segments instead of storing a full preconverted MP4 copy.
No. Preview jobs are part of the product queue, and maintenance work can use upload activity and quiet-hour signals to skip, delay, or pace heavier background jobs.
No. Previews are generated by authorized server paths from the storage pipeline. For client-side encrypted folders, preview behavior must respect the client-side encryption boundary.
Yes, when the shared file type is supported and the share access allows it. The point is to make a link understandable before the recipient has to download the file.