Cách xử lý PDF phía client hoạt động (ngay trong trình duyệt, không tải lên)

“Chạy trong trình duyệt của bạn” là lời khẳng định mà gần như trang PDF nào cũng ghi đâu đó ở footer. Nhưng phần lớn trong số đó vẫn âm thầm tải file của bạn lên. Dưới đây là những gì thực sự phải đúng để lời khẳng định đó có ý nghĩa, và cách bạn tự kiểm tra trong chưa đầy một phút.

Kiến trúc làm nên điều đó: WebAssembly

Xử lý PDF thực sự — ghép trang, mã hóa lại ảnh, viết lại một luồng dữ liệu đã mã hóa — cần những thư viện cấp thấp giống hệt các ứng dụng native sử dụng. Trình duyệt không thể chạy trực tiếp C/C++/Rust, nhưng có thể chạy WebAssembly (WASM): những thư viện đó được biên dịch thành định dạng nhị phân mà trình duyệt thực thi với tốc độ gần như mã máy gốc.

Đó chính là khác biệt giữa một công cụ chạy phía client thật sự và một công cụ “chạy trên trình duyệt” thực chất chỉ là một form tải lên đẹp hơn. Một trang có ô kéo-thả và thanh tiến trình vẫn có thể âm thầm POST file của bạn lên máy chủ ngay khi bạn thả vào. WASM là thứ cho phép việc xử lý thật sự — chứ không chỉ giao diện — diễn ra tại chỗ.

Vì sao chạy trong Web Worker, không phải luồng chính

Giải mã và viết lại một PDF 100 trang là việc tốn CPU thật sự. Nếu làm trên luồng chính của trình duyệt, trang sẽ bị đơ — không cuộn được, không bấm được, và cảnh báo “tab không phản hồi” sẽ xuất hiện với bất kỳ file nào đủ lớn. Một Web Worker chạy công việc đó trên một luồng nền, nhờ vậy giao diện vẫn phản hồi mượt và bạn có thanh tiến trình thời gian thực thay vì một tab đứng hình. Byte của file được đọc vào bộ nhớ, chuyển cho worker, xử lý, rồi trả lại — tất cả đều diễn ra bên trong tiến trình trình duyệt của bạn. Không bước nào trong luồng này cần đến máy chủ, hay có lợi gì từ việc có máy chủ.

“Không tải lên” thực sự loại trừ điều gì

Nếu một công cụ thực sự chạy phía client, ba điều sau sẽ đúng, và cả ba đều kiểm tra được:

• Không có endpoint tải lên. Không có /api/upload hay bất kỳ thứ tương tự nào để công cụ gọi đến — vì chẳng có gì ở đầu kia để gọi.
• Không có độ trễ xử lý phụ thuộc vào dung lượng file và tốc độ mạng. Một file 200 MB qua đường truyền chậm sẽ tải lên rất lâu; một công cụ chạy phía client với cùng file đó chỉ bị giới hạn bởi CPU của thiết bị, và bắt đầu xử lý ngay lập tức.
• Hoạt động offline. Sau khi trang đã tải xong một lần (và với một PWA, đã được service worker cache lại), công cụ vẫn tiếp tục hoạt động dù không có kết nối internet nào — vì nó chưa bao giờ cần internet để làm việc.

Cách tự kiểm chứng

Bạn không cần tin suông vào một lời khẳng định về quyền riêng tư:

1. Mở DevTools → tab Network trước khi chạy công cụ, rồi xử lý một file. Theo dõi xem có request nào có kích thước payload tăng theo dung lượng file của bạn không. Nếu không thấy gì như vậy, file đã không rời khỏi trình duyệt.
2. Ngắt kết nối internet, rồi thử lại công cụ (sau khi trang đã tải xong). Nếu vẫn hoạt động, nghĩa là không có máy chủ nào tham gia vào quá trình.
3. Kiểm tra dung lượng trang, chứ không chỉ lời khẳng định. Một công cụ thực sự xử lý tại chỗ sẽ tải một engine WASM — thường là một chunk lazy-load nặng vài trăm KB đến vài MB trong lần đầu bạn dùng công cụ đó — thay vì một đoạn script nhỏ chỉ để gửi một form.

Đây chính xác là cách HivePDF được xây dựng: mọi công cụ — Ghép PDF, Nén PDF, Bảo Vệ PDF, Bôi đen PDF, Ký PDF, và tất cả những công cụ còn lại — đều chạy qua một engine WASM riêng cho từng tác vụ, bên trong một Web Worker, không có endpoint tải lên nào phía sau. Để hiểu sâu hơn về ý nghĩa thực tế của điều này, xem thêm công cụ PDF online có an toàn không và bài so sánh kiến trúc thẳng thắn với các công cụ chạy trên máy chủ.