Cara Kerja Pemrosesan PDF Client-Side (di Browser, Tanpa Upload)

“Berjalan di browser Anda” adalah klaim yang hampir dibuat oleh setiap situs PDF di suatu tempat pada footer-nya. Kebanyakan dari mereka tetap mengunggah file Anda. Berikut apa yang sebenarnya harus benar agar klaim itu terbukti, dan cara memeriksanya sendiri dalam waktu kurang dari semenit.

Arsitektur yang membuat ini mungkin: WebAssembly

Manipulasi PDF yang sesungguhnya — menggabungkan halaman, mengenkode ulang gambar, menulis ulang stream terenkripsi — membutuhkan pustaka tingkat rendah yang sama dengan yang digunakan aplikasi native. Browser tidak bisa menjalankan C/C++/Rust secara langsung, tapi bisa menjalankan WebAssembly (WASM): pustaka-pustaka tersebut dikompilasi ke dalam format biner yang dieksekusi browser dengan kecepatan hampir native.

Itulah bedanya alat client-side dengan alat “berbasis browser” yang sebenarnya cuma formulir unggah yang lebih cantik. Halaman dengan kotak drag-and-drop dan progress bar tetap bisa diam-diam melakukan POST file Anda ke server begitu Anda menjatuhkannya. WASM-lah yang memungkinkan pemrosesan sesungguhnya — bukan sekadar UI — terjadi secara lokal.

Kenapa berjalan di Web Worker, bukan thread utama

Mendekode dan menulis ulang PDF 100 halaman adalah pekerjaan CPU yang sungguhan. Melakukannya di thread utama browser akan membuat halaman macet — tidak bisa scroll, tidak bisa klik, peringatan “tab tidak merespons” untuk apa pun yang besar. Web Worker menjalankan pekerjaan itu di thread latar belakang sebagai gantinya, sehingga antarmuka tetap responsif dan Anda mendapatkan progress bar langsung, bukan tab yang macet. Byte file dibaca ke memori, diserahkan ke worker, diproses, dan dikembalikan — semuanya di dalam proses browser Anda. Tidak ada bagian dari alur itu yang membutuhkan atau diuntungkan oleh server.

Apa sebenarnya yang disingkirkan oleh “tanpa upload”

Jika sebuah alat benar-benar client-side, ada tiga konsekuensi, dan ketiganya bisa diperiksa:

• Tidak ada endpoint upload. Tidak ada /api/upload atau yang setara untuk dipanggil alat tersebut — karena tidak ada apa pun di ujung lain untuk memanggilnya.
• Tidak ada jeda pemrosesan yang terkait ukuran file dan kecepatan koneksi. File 200 MB melalui koneksi lambat butuh waktu lama untuk diunggah; alat client-side dengan file yang sama hanya dibatasi oleh CPU perangkat Anda, dan mulai bekerja secara instan.
• Berfungsi offline. Setelah halaman dimuat sekali (dan untuk PWA, di-cache oleh service worker), alat tersebut terus berfungsi tanpa koneksi internet sama sekali — karena memang tidak pernah butuh koneksi untuk menyelesaikan pekerjaannya.

Cara memverifikasi sendiri

Anda tidak harus percaya begitu saja pada klaim privasi:

1. Buka DevTools → tab Network sebelum menjalankan alat, lalu proses sebuah file. Perhatikan permintaan apa pun yang ukuran payload-nya mengikuti ukuran file Anda. Jika tidak ada yang seperti itu muncul, file tidak meninggalkan browser.
2. Putuskan koneksi internet, lalu coba alat tersebut lagi (setelah halaman itu sendiri sudah dimuat). Jika masih berfungsi, tidak ada server dalam alurnya.
3. Periksa berat halaman, bukan cuma klaimnya. Alat yang benar-benar bekerja secara lokal akan memuat mesin WASM — sering kali sebuah chunk lazy-load berukuran beberapa ratus KB hingga beberapa MB saat pertama kali Anda menggunakan alat spesifik itu — alih-alih skrip kecil yang cuma mengirim formulir.

Begitulah tepatnya cara HivePDF dibangun: setiap alat — gabung, kompres, proteksi, redaksi, tanda tangan, dan lainnya — berjalan melalui mesin WASM khusus per tugas di dalam Web Worker, tanpa endpoint upload di baliknya. Untuk penjelasan lebih dalam tentang apa artinya ini dalam praktik, lihat apakah alat PDF online aman dan perbandingan arsitektur yang jujur dengan alat berbasis server.