Domande frequenti

No. Ogni strumento PDFluna gira completamente nel tuo browser grazie a JavaScript, WebAssembly e alla libreria di rendering PDF integrata nel browser. I tuoi file vengono letti localmente, processati localmente e salvati localmente. Puoi verificarlo tu stesso: apri DevTools → scheda Rete prima di usare uno strumento, e osserva — vedrai zero richieste in uscita che trasportano il tuo file. L'unico traffico di rete è il caricamento iniziale della pagina e le librerie open source (PDF.js, pdf-lib, ecc.) di cui lo strumento ha bisogno.

No. Non possiamo — i file non raggiungono mai i nostri server, in primo luogo. Non c'è nessuna "policy di cancellazione dei file" dalla nostra parte perché non ci sono file da cancellare dalla nostra parte. Non usiamo i contenuti dei file per addestrare IA, profilare la pubblicità, fare analisi statistiche o simili.

Sì. La forma più forte di conformità GDPR è non raccogliere dati personali in primo luogo, e questo è il nostro comportamento predefinito. Non richiediamo un account, non trattiamo il contenuto dei file sulla nostra infrastruttura, e gli unici dati che il sito raccoglie sono analytics anonime (visualizzazioni di pagina, conteggi di utilizzo degli strumenti — nessun identificativo personale, nessun contenuto di file). Per richieste specifiche di protezione dei dati o DSAR (richiesta di accesso ai dati personali), scrivi a [email protected]. Dettagli completi nella nostra privacy policy.

Sì — in realtà più sicuro della maggior parte delle alternative. I concorrenti lato server (iLovePDF, Smallpdf, gli strumenti online di Adobe) caricano tutti i tuoi file sulla loro infrastruttura, li elaborano lì e ti restituiscono l'output. Per un contratto, una busta paga, un referto medico o un documento d'identità, è un'esposizione significativa anche se la loro privacy policy fosse impeccabile: il tuo file vive brevemente in un posto che non controlli. Con PDFluna, quella esposizione semplicemente non esiste — il file non attraversa mai la rete.

No, e non ne abbiamo bisogno per come operiamo. SOC 2 / ISO 27001 verificano come un'organizzazione gestisce i dati dei clienti sui suoi server. Dato che non gestiamo dati di file dei clienti sui nostri server (restano sui tuoi), non c'è nulla da esaminare in queste audit. L'equivalente più vicino è il codice open source stesso: ogni libreria che usiamo (PDF.js, pdf-lib, fflate, html2canvas) è pubblicamente verificabile, e i DevTools del tuo browser ti permettono di confermare in tempo reale che nessun file lascia il tuo dispositivo.

Usiamo Google Analytics 4 per contare le visualizzazioni di pagina anonime e aggregare l'uso degli strumenti. Nessun nome di file, nessun contenuto di file, nessuna informazione identificativa. I visitatori UE che rifiutano il banner di consenso ricevono analytics Plausible senza cookie. Entrambi sono configurabili nella nostra policy sui cookie; rifiutare non influisce sulla funzionalità degli strumenti.

I browser moderni possono fare molto più che renderizzare pagine web. JavaScript e WebAssembly ci permettono di eseguire vere librerie PDF (PDF.js, pdf-lib) direttamente nella scheda del browser, con accesso completo al file che selezioni dal selettore o trascini. Il file viene letto nella memoria della scheda, elaborato lì, e il risultato viene offerto per il download. La stessa tecnologia alimenta Figma, Photoshop sul web e Google Docs.

Perché non c'è nessun upload. Le barre di avanzamento negli strumenti PDFluna seguono l'elaborazione locale — quanto del tuo file la libreria del browser ha letto, codificato o stampato — non il trasferimento di rete. Su un computer veloce a volte è quasi istantaneo, il che può sembrare sospetto se sei abituato agli upload di diversi secondi degli strumenti server, ma la velocità è il vantaggio del saltare completamente il round-trip di rete.

La prima volta che usi uno strumento pesante (OCR, firma, Word in PDF), carichiamo on-demand una libreria specializzata — Tesseract.js per l'OCR (~14 MB), mammoth.js per il parsing di Word (~150 KB con gzip), e così via. Queste librerie vengono memorizzate nella cache del tuo browser dopo il primo caricamento, quindi il secondo utilizzo è istantaneo. Deliberatamente non le carichiamo sulla home page per mantenere veloce il time-to-interactive della landing.

Parzialmente. Una volta che hai usato uno strumento e la pagina + le librerie sono nella cache del tuo browser, di solito puoi ricaricare lo stesso strumento offline e funzionerà. Attualmente non distribuiamo un Service Worker per l'uso offline esplicito, quindi un ricaricamento che richiede di scaricare nuovi asset fallirà offline. L'uso offline reale è nella roadmap.

La maggior parte degli strumenti accetta PDF fino a 100 MB. Gli strumenti di conversione di formato (Word in PDF, Excel in PDF) limitano a 20 MB perché il parsing di questi formati è più pesante in memoria. L'OCR limita a 50 MB / 50 pagine perché ogni pagina viene renderizzata a 300 DPI e poi sottoposta a OCR, che è la pipeline più lenta che proponiamo. I limiti specifici sono indicati sulla pagina di ogni strumento sopra la zona di rilascio.

PDF (ogni strumento), immagini (JPG, PNG, HEIC, WebP — per JPG in PDF), documenti Word (.docx, .rtf, .odt — per Word in PDF), fogli di calcolo (.xlsx, .xls, .ods, .csv, .tsv — per Excel in PDF), e immagini di firma (PNG, JPG, GIF, WebP — per Firma PDF).

PDF (predefinito per tutto), JPG (uno per pagina o uno ZIP per multi-pagina via PDF in JPG), e PNG (uno per pagina o uno ZIP via PDF in PNG). Non produciamo Word, PowerPoint o Excel da PDF — la conversione inversa verso formati a flusso / griglia è davvero difficile e non vogliamo proporre uno strumento il cui output sarebbe inutilizzabile. Vedi il blog per il ragionamento completo se sei curioso.

Il formato binario legacy .doc di Word 97–2003 richiede o lo stesso Microsoft Word o un parser personalizzato di diverse migliaia di righe per convertire con fedeltà accettabile. Preferiamo rifiutare in modo pulito piuttosto che proporre uno strumento il cui output verrebbe paragonato sfavorevolmente con altri servizi. La soluzione di 10 secondi: apri il tuo .doc in Word o LibreOffice, File → Salva come → .docx, e rilascia il .docx nel nostro strumento Word in PDF. Tutto è preservato.

Alcuni strumenti sì (Unisci PDF accetta più file per design; JPG in PDF accetta un batch di immagini). La maggior parte è uno alla volta, intenzionalmente: spingere cinque file da 50 MB nel browser simultaneamente farebbe crashare i telefoni di fascia media. Il flusso di batch più veloce per compressione / conversione è eseguirli in sequenza nella stessa scheda — lo strumento si reinizializza istantaneamente tra i file.

Scrivi a [email protected] con il prefisso oggetto `[Bug]` o `[Feature request]`. Per i bug, allegare il file (se condivisibile) e indicare browser + SO accelera la riproduzione di circa 10×. Leggiamo ogni messaggio; risposta entro 1-2 giorni lavorativi per le domande generali.

Tutti i browser recenti: Chrome 120+, Edge 120+, Safari 17+, Firefox 120+, e i loro equivalenti mobile (iOS Safari 17+, Android Chrome). Le versioni più vecchie possono funzionare per gli strumenti più semplici, ma non li testiamo — le API WebAssembly + Pointer Events su cui ci appoggiamo sono solide solo nelle versioni recenti.

Sì. iOS Safari 17+ supporta tutto tranne alcuni casi estremi di documenti molto lunghi in cui la scheda del browser esaurisce la memoria prima della fine della ricostruzione. Come regola generale, i file sotto i 30 MB vanno bene sui telefoni; i tablet (iPad Air 5+ o più recente) gestiscono il limite completo di 100 MB nella maggior parte degli strumenti.

Sì — su Chrome, Firefox, Edge e Samsung Internet recenti. I dispositivi di fascia bassa (4 GB di RAM o meno) possono interrompersi a metà su file grandi per la stessa pressione di memoria che su iPhone; se uno strumento fallisce su un documento lungo, dividere prima con Dividi PDF di solito permette di passare.

L'elaborazione PDF è intensiva in CPU e memoria. Un PDF da 100 MB può richiedere 300-500 MB di memoria di lavoro per essere renderizzato e ri-emesso, che è più di quanto i telefoni vecchi (4 GB di RAM totale di sistema) possano allocare per una singola scheda del browser. Soluzioni: dividi prima il documento con Dividi PDF, abbassa il DPI di output negli strumenti di rasterizzazione (PDF in JPG, OCR PDF), o esegui sul computer.

Per la maggior parte degli strumenti, sì — operiamo sulla struttura binaria PDF esistente invece di renderizzare di nuovo, quindi le pagine mantengono il loro testo vettoriale originale, i font incorporati e la qualità delle immagini. Eccezioni: Word in PDF, Excel in PDF e Sblocca PDF ricostruiscono il documento come image-based (fedeltà visiva preservata, ma perdi i campi modulo e il testo selezionabile). La pagina di ogni strumento documenta il compromesso.

Il nostro strumento Comprimi PDF usa un aggiornamento incrementale, quindi il testo originale, i font e le firme sono preservati byte per byte. I risparmi di spazio derivano dalla ricodifica delle immagini incorporate a risoluzioni inferiori e dalla rimozione di oggetti storici ridondanti. Per i PDF ricchi di testo, il risultato visivo è indistinguibile dall'originale; per i PDF ricchi di immagini (scansioni, basati su foto), puoi scegliere il livello di compromesso.

PNG è senza perdita — ogni pixel della pagina renderizzata è preservato esattamente. JPG è con perdita e produce file più piccoli ma aggiunge sottili aloni intorno ai bordi netti (testo, line-art). I preset DPI S/M/L (72 / 150 / 300) controllano la risoluzione; lo slider di qualità JPG (60-95 %) controlla la compressione. Stessa libreria sorgente, strategia di output diversa — scegli in base alle tue esigenze.

Alcuni dei nostri strumenti (Sblocca PDF e la famiglia di conversione) producono un output image-based dove ogni pagina viene renderizzata come JPEG e incorporata in un nuovo PDF. JPEG a 200 DPI su carta letter pesa in media 250-500 KB per pagina, che può essere più grande dell'originale se questo era solo testo vettoriale. Per ridurre il risultato, passalo dal nostro strumento Comprimi PDF.

Sì, e non c'è registrazione, nessuna filigrana, nessun "limite di esportazione" o "3 file al giorno". La fregatura (se ce n'è una): il sito mostra annunci sulle pagine degli strumenti e sulle pagine dei contenuti. I ricavi pubblicitari coprono hosting e sviluppo; quello è tutto il modello di business. Non pianifichiamo di introdurre piani a pagamento, e i nostri costi infrastrutturali sono minimi proprio perché tutto il lavoro pesante gira nel tuo browser.

Perché non c'è nulla che un account dovrebbe memorizzare. Non conserviamo i tuoi file, la tua cronologia o le tue impostazioni. Non avere account significa anche non avere password da ricordare e nessun flusso "ho dimenticato la password" quando torni due mesi dopo. Il compromesso: nessuna continuità tra dispositivi (non puoi iniziare un'attività sul computer e finirla sul cellulare). Per le attività PDF occasionali, è la forma giusta; per i flussi continui di documenti, un SaaS a pagamento come Adobe Acrobat è la scelta migliore.

Sì per il set attuale di strumenti. I nostri costi infrastrutturali scalano con il traffico ma restano bassi perché niente accade sul server; i ricavi pubblicitari li coprono comodamente. Se il progetto un giorno avesse bisogno di introdurre piani a pagamento, sarebbe per nuove funzionalità lato server (editing collaborativo, sincronizzazione tra dispositivi) e gli strumenti attuali nel browser resterebbero gratis.

Sì. PDFluna non rivendica diritti sui tuoi file in entrata né sul nostro output. Il PDF che produci è tuo da usare come ritieni opportuno — lavoro commerciale, consegne ai clienti, archiviazione, condivisione, qualsiasi cosa. L'unica restrizione è il diritto d'autore del contenuto originale (non lo cambiamo, e non possiamo concedere diritti che non abbiamo).

Una piccola squadra indipendente. Abbiamo costruito PDFluna perché noi stessi avevamo bisogno di strumenti PDF veloci ed eravamo frustrati dalle alternative upload-to-server. La pagina Chi siamo completa ha più dettagli sul perché e come. Per contatti specifici, vedi la pagina contatti.