[FEATURE] File Size Validation

[0rigin-c0de]

Problem

No validation for file sizes before uploading. Large files can cause browser crashes or storage issues.
Users can accidentally upload huge files, causing performance problems.

Solution

Pre-upload Validation with Hard Limits

• Validate file size before processing starts
• Reject files exceeding configured limits immediately
• Show clear error messages with file size info
• Different limits for images, videos, and audio
• Pros: Simple, prevents issues early
• Cons: May be too restrictive for some use cases

Alternative

Approach 1: Soft Limits with Warnings

• Allow uploads but show warnings for large files
• Provide "Continue anyway" option
• Track large files separately
• Pros: Flexible, user-friendly
• Cons: Users might ignore warnings

Approach 2: Progressive Upload with Chunking

• Split large files into chunks
• Upload chunks progressively
• Validate chunk size
• Pros: Handles very large files, better UX
• Cons: Complex implementation, requires chunking logic

Implementation Details:

• Add file size limits (configurable, with sensible defaults)
  • Images: 50MB default, configurable up to 200MB
  • Videos: 500MB default, configurable up to 2GB
  • Audio: 100MB default, configurable up to 500MB
• Show warnings for large files with file size info
• Provide file size information in media panel (already have file.size)
• Option to compress images before adding (using browser-image-compression or similar)
• Check available quota using navigator.storage.estimate()
• Display storage usage indicator

Anything else?

No response

[BlackCatOfficialytb]

i think it need to have default limit like you, but can configurable up to unlimited
this way it'll better to making windows/mac/linux/bsd version, or making it more popular

[0rigin-c0de]

@BlackCatOfficialytb Got it, thanks for the suggestion. I’ll consider making the limits configurable, including an unlimited option for advanced use cases

[lokeshkarthik5]

@0rigin-c0de Are you implementing "Approach 2" for this feature?

[Kushagra-Agarwal22]

I had write few approaches

1. Pre‑signed URL + direct‑to‑storage
a Store media in S3/Cloudflare R2/Supabase/Backblaze etc., not your app server.

   b  Your backend only issues a short‑lived pre‑signed URL (with max size constraints) and the browser             
        uploads directly to storage using PUT or multipart upload.​

**Benefits:**

a Your Node server doesn’t get overwhelmed by huge bodies.

b You can enforce hard limits in the storage policy (e.g., max object size, allowed MIME types).

2. Resumable, chunked, and throttled
   a Combine pre‑signed uploads with resumable/chunked uploads:

   b Use a library/protocol like tus.io or a custom “uploadId + chunk index” API, so large files resume after
   network errors.​

   c For each chunk, you still apply a per‑chunk size limit (e.g., 5–10 MB) and timeouts, which caps memory
   and bandwidth usage.

On slow networks, you can throttle upload speed (server‑side or via client timers) to avoid user’s bandwidth being saturated.​

3. Client‑side pre‑processing (optional but powerful)
a For video: offer “optimize before upload” using ffmpeg.wasm to downscale resolution or bitrate
inside the browser for preview / editing copies.​

For images: compress aggressively at the client (as you already plan) and upload original only if user explicitly chooses “Export in original quality.”​

This approach, combined with your existing hard/soft limits and chunking, gives:

Safety (clear max object size in storage + per‑chunk limits),

Reliability (resumable uploads, no crashes on reload),

Scalability (backend stays lightweight while handling editor logic, not GB‑sized streams).

[lokeshkarthik5]

Okay. The first approach could work for this. Hybrid approach of presigned URL + async flow.