Know where your file is processed.

PWRKIT uses browser processing when the required operation can run safely and reliably with browser APIs or bundled client libraries. In that mode, the selected file or entered text stays in the current browser tab. The workbench creates a separate result for copying or download and does not send the source to a PWRKIT processing server.

Operations that require native document, archive, image, font, audio, or video software use a private worker. The tool page identifies this mode before processing begins. The application validates the request, sends the file to the worker, receives the generated result, and returns it to the browser. Processing mode depends on the route, not only on the broad file category.

Browser processing still uses device resources. Large images, long documents, and multi-file jobs can consume substantial memory while the source, decoded data, preview, and result coexist. Closing or reloading the tab interrupts that work and can discard an output that has not been downloaded. A browser route avoids a file transfer to PWRKIT, but it does not promise that every device can complete every file near the published size limit.

A filename extension and browser-reported media type are not enough to identify a file. Conversion routes inspect format signatures before accepting input. The request is rejected when the declared type conflicts with the bytes, when a required structure is missing, or when the selected route does not support the detected format.

Each operation also applies bounded settings and file limits. These checks cover values such as dimensions, page ranges, frame counts, archive entries, expanded archive size, and output size where they apply. The exact controls and limits are shown on the relevant tool or converter page because one global number would misdescribe several routes.

Validation happens again when an operation has more than one input. A GIF job checks every frame, a subtitle job checks both the video and subtitle file, and archive creation checks the selected filenames and total package. Page-based operations normalize ranges against the document’s page count. Rejecting a job before conversion avoids passing unsupported or contradictory input deeper into the processing chain.

The private worker creates a temporary job directory and uses fixed internal filenames. Native programs receive argument arrays rather than shell-built commands. The original upload name does not become a command or worker path. Jobs are bounded by configured input size, output size, processing time, and concurrency limits.

The worker removes the temporary job directory after success and after handled rejection, timeout, or cancellation. A successful result is returned only after the operation completes its output checks. PWRKIT does not describe worker processing as local browser processing, and the privacy policy explains the distinction for visitors deciding whether a route fits their requirements.

Cancellation is carried through the request path so the worker can stop an active engine instead of continuing an unwanted job in the background. Timeouts and concurrency limits prevent one request from occupying a worker indefinitely. A busy or unavailable worker returns an error rather than silently moving the operation to a different processor with different privacy or output behavior.

Where the selected engine supports it, PWRKIT checks the generated file signature or parses the output before returning a download. Document, archive, image, media, font, and PDF operations have format-specific checks. These checks can catch a missing, empty, malformed, or wrongly typed result.

A valid file can still be unsuitable for its destination. Conversion may simplify layout, remove metadata, flatten transparency, select one animation frame, change codecs, or omit a feature that the destination format cannot represent. Every consequential output should be opened in the application where it will be used and compared with the source.

Output inspection should match the task. For an image, confirm dimensions, orientation, transparency, color, and animation. For a document, inspect headings, tables, links, page breaks, reading order, and non-ASCII text. For media, check duration, codecs, audio presence, subtitle tracks, and playback in the destination. For an archive, list the entries and extract a copy into a safe temporary folder before replacing the source package.

Browser processing reduces file transfer because the source remains on the device, but it does not make the surrounding device or browser trusted. Clipboard history, extensions, screenshots, local backups, shared devices, and downloaded files can still expose sensitive material. Visitors should follow their organization’s handling rules before using any online utility.

Private worker routes transfer the selected file for the duration of the conversion request. Temporary-job cleanup limits retention inside the worker process, but it is not a substitute for authorization, classification, or a regulated-data agreement. Do not upload material when its handling policy forbids this processing model.

The safest test input is a small synthetic file that reproduces the required structure without names, secrets, customer records, or production content. Replace confidential values before testing text tools. For a file conversion problem, create a minimal fixture in the same format when possible. A reduced fixture is easier to inspect, share with authorization, and retain as a regression test after the defect is fixed.

Tool descriptions are checked against the current implementation, registered processor, option schema, and automated tests. Browser tools are tested for representative success and failure paths. Worker routes use fixture files to verify request validation, engine behavior, output signatures, and cleanup. Public copy is corrected when it conflicts with the behavior under test.

The processing method can change when an operation gains a new engine or outgrows browser limits. The route label, privacy explanation, tests, and public documentation must change together. Reports can be sent through the contact page with a non-sensitive fixture, the affected URL, the observed result, and the expected behavior.

Automated tests do not prove that every valid file in a format will behave identically. Formats can contain optional features, vendor extensions, damaged structures, unusual color profiles, large embedded resources, or combinations absent from the fixtures. Tests establish the behavior of known examples and guarded failure paths. A new reproducible case should become a focused test when it exposes an unsupported assumption or regression. Record the browser, operating system, source format, selected settings, and visible error when reporting a browser-specific result.

A conversion engine is chosen for the structures it can read and write. Browser canvas APIs cover many still-image operations, while native image software handles formats the browser cannot decode consistently. FFmpeg processes audio, video, subtitles, and animation. Pandoc translates supported document structures. Poppler reads PDF pages and text, qpdf handles supported PDF security operations, and archive tools inspect and repackage bounded file sets.

Sharing an engine does not make two routes equivalent. MOV to MP4 can copy compatible streams or transcode incompatible video and audio. RTF to Markdown maps rich-text structure into plain-text markup and cannot preserve page geometry. AVIF to ICO changes an image into an icon container, but the destination still needs review at small display sizes. Each route adds its own option schema, limits, quality notes, and result checks around the engine.

Engine names describe implementation, not an endorsement or a guarantee of universal compatibility. A destination application can impose a narrower profile than the file format permits. An MP4 file may use an unsupported codec, a valid ICO may omit a size expected by a particular application, and a DOCX can render differently across office suites. Verify against the named destination instead of treating the extension as the whole contract.

Archives are containers for paths and file entries, so their risks differ from a single image or text value. PWRKIT checks for unsafe paths, duplicate destinations, unsupported entry types, excessive entry counts, expanded-size limits, and suspicious compression ratios before supported extraction or repackaging. A rejected archive should be inspected with authorized offline software rather than weakened until it passes.

Document conversion separates readable content from fixed presentation. Word-processing formats can represent headings, lists, tables, styles, links, metadata, and page layout in different ways. Markdown and plain text represent much less. PDF fixes page appearance but may contain selectable text, scanned images, forms, annotations, embedded files, or encryption. The selected route states which part of that structure it processes.

Keep the source until the result has passed content and visual review. Do not overwrite an only copy after a successful download. For recurring work, retain a small approved fixture and a checklist for the details that matter to the destination. That record makes a later engine or browser change easier to detect than relying on memory or comparing filenames alone.