Privacy, plainly.

Every file tool states whether it uses browser processing or a private worker. Browser-labeled operations read compatible files with browser APIs and create outputs in the browser session without sending the source file to a PWRKIT processing server. Private-worker operations upload the selected file, process it in an isolated temporary job directory, validate the output, and remove the job directory afterward. Text transformations and calculator operations run in page code unless a tool states otherwise.

The processing label describes where the operation occurs. It does not mean that everything visible in a browser is secret from the device or network environment. Browser extensions, clipboard managers, screen-recording software, device administration, and local backups can operate according to their own permissions. A visitor should use an environment permitted by the rules that apply to the material. Closing a page or resetting a workbench clears the displayed tool state, but it does not erase copies already downloaded, pasted, captured, or stored by other software.

A file selected for a PDF or image tool is loaded by the browser for that operation. The workbench may show its filename, size, page count, dimensions, or preview locally so the visitor can check the source. Generated PDFs, ZIP archives, images, QR codes, and text results remain available in the page until they are downloaded, copied, reset, replaced, or lost through navigation. PWRKIT does not provide an account-based file library, conversion history, or recovery area for these outputs.

Tool input can still contain personal or confidential information even when the transformation is local. A document may show a name in its pixels, a URL may contain a token, and an image may expose a location visually after metadata is removed. PWRKIT's tools do not classify sensitivity or decide whether a visitor has permission to handle the material. Remove or replace sensitive values when they are unnecessary, keep originals in an approved location, and inspect generated output before sharing it with another person or service.

When configured, Google Analytics 4 is delivered through Google Tag Manager. The application pushes bounded interaction events into a browser data layer, and the configured tag setup handles delivery. The measurements cover page visits, navigation, workbench stages, processing duration, broad outcomes, and categorized characteristics such as length, quantity, format, or file-size buckets. The application does not load the GA4 library directly as a separate transport alongside Google Tag Manager.

Cloudflare Web Analytics provides aggregate traffic and performance measurement when that service is active for the deployed site. Its purpose differs from the workbench event stream. Aggregate traffic can help compare coverage and page performance, while named tool events describe stages such as selecting input, attempting an operation, receiving a broad success or error result, copying, or downloading. Browser controls, blockers, and consent choices can prevent or limit either measurement path, so reported totals need not equal all visits.

The analytics event contract excludes tool input, generated output, file contents, filenames, search phrases, entered URLs, dates, financial values, and raw error messages. Instead of sending a full value, the application uses stable identifiers, booleans, enumerations, counts, durations, and broad buckets. For example, an event can describe that a field has a value or that an input length falls inside a range without including the field's text. File events categorize count, broad size, and general type rather than attaching the selected file.

This distinction applies to the application-owned events visible in the current implementation. It should not be read as a statement about every browser extension, network intermediary, destination opened from a link, or external service a visitor may use before or after PWRKIT. Analytics exclusions also do not make a sensitive action appropriate by themselves. Visitors should avoid entering prohibited material, and changes to measurement must continue to preserve the documented exclusions rather than adding raw values for easier debugging.

PWRKIT can send the current page path to its own page-view endpoint. The corresponding database record contains a path and creation timestamp when database storage is available. A path can still reveal which public tool or category was visited, and query strings are not used as the application page path in the route event shown here. This first-party record is separate from the more detailed Google Tag Manager event flow and from Cloudflare's aggregate measurement.

Catalog search activity can be posted to PWRKIT's search endpoint. A valid search is trimmed, limited to 2 through 200 characters, and can include an optional tool identifier. When a database is configured, the search phrase, optional tool value, and creation timestamp can be stored. Search text is therefore different from ordinary workbench input. Visitors should not place credentials, private names, personal records, or other sensitive information into the catalog search box. The search endpoint is also rate-limited and returns no-store responses.

This policy does not state a fixed retention period for first-party page or search records. It also does not promise that a database is configured in every environment. Operational decisions about access, retention, and deletion must remain consistent with the deployed system and applicable obligations. The public notice should be updated if the stored fields or their purpose changes. Search phrases must remain outside the application analytics event payload described above.

PWRKIT has no visitor account system. The current tools do not ask a visitor to create a profile before using a workbench, and the site does not offer an account dashboard containing saved inputs or prior outputs. This reduces the account data that PWRKIT itself asks visitors to provide. It also means there is no account-based synchronization, access history, saved-project area, or password recovery workflow for tool activity.

No-account access does not make every visit anonymous in an absolute sense and should not be described that way. Traffic services, first-party page records, search records, ordinary server infrastructure, and the visitor's own environment are separate from an account profile. A path or campaign link can contain information chosen by the person who constructed it. Visitors should review addresses before sharing them and should not treat URL encoding, UTM parameters, or QR codes as encryption.

Browser privacy settings, content blockers, and applicable consent controls may restrict analytics scripts or requests. Their behavior depends on the visitor's browser, extensions, network, and the deployed consent setup. PWRKIT cannot promise that one control has the same effect in every environment. A visitor who needs to verify network activity can use browser developer tools or another approved inspection method to observe requests during a representative session.

Resetting a workbench clears its current fields and generated result from the page state. Closing or reloading the page normally removes unsaved workbench state, but those actions do not delete downloaded files, clipboard contents, browser history, external logs, or a search record already submitted. Use the control that matches the location of the data. Delete local downloads through the device's file controls and avoid submitting sensitive search text in the first place.

A PWRKIT tool can prepare a URL, QR code, metadata preview, social-card draft, or other output intended for another platform. Creating that output locally does not control what happens when the visitor opens, uploads, publishes, or sends it. The destination can receive the supplied value and apply its own logging, account, cookie, analytics, moderation, and retention behavior. Review the destination and its notices before moving information out of the local workbench.

Remote image URLs entered into the OpenGraph preview can cause the browser to request the image from its host so the card can display it. Links followed from PWRKIT likewise become requests to the destination. The local-processing statement for tool copy does not mean that a remote resource can be displayed without contacting its host. Avoid signed, private, or identifying URLs in a preview unless their use is permitted, and remember that query parameters can be copied into logs after navigation.

Privacy documentation must stay aligned with code and deployment. A change that sends raw fields, adds an account, introduces a new storage table, changes search logging, enables another external service, or alters consent handling requires review before release. Tests should inspect event payloads and network requests, not only visible copy. Production verification remains necessary because environment configuration decides whether Google Tag Manager is loaded and external dashboards determine what configured tags receive.

Privacy questions or concerns can be sent through the public contact route at hello@pwrkit.cloud. Do not include confidential source files, credentials, private tool input, or other sensitive material in the message. A useful report identifies the page or tool, the observed behavior, the browser environment, and the concern without reproducing protected content. PWRKIT's public policy should describe confirmed practices plainly and be corrected when implementation evidence no longer matches it.

A statement about PWRKIT application analytics does not automatically describe first-party search storage, Cloudflare measurement, the destination of an outbound link, or software installed on the visitor's device. These paths are described separately because they receive different kinds of information for different purposes. When reviewing a concern, identify the action, the value involved, the code path, and the recipient rather than applying one general label to every browser event.

Likewise, a statement that a tool operates locally applies to the transformation itself. It does not claim that an entered remote image can display without a request, that a downloaded file disappears automatically, or that another service will handle a copied result under PWRKIT's rules. Clear boundaries make the notice testable. If a future implementation crosses one of them, the behavior and public explanation should be reviewed together before the changed path is treated as covered.