Privacy, cookies, and advertising

1. Tool input and files you provide

JSON, JSONL, NDJSON, repair input, YAML documents, YAML or JSON conversion output, SQL queries and formatted SQL, XML documents and formatted or tree-view output, URLs, query strings, timestamps, dates, timezones, Base64 text, Data URLs, selected files, decoded bytes, text or file hash input, expected digests and checksums, UUID or GUID input, generated identifiers, compact JWT or Bearer token input, decoded JOSE headers, JWT claims, signature bytes, and other generated output are processed in the current browser tab. The tools do not submit that content to a LiveParse application server, formatter API, database server, or analytics system. Formatting, warnings, tree search, repair, encoding, decoding, parsing, hashing, checksum comparison, conversion, validation, normalization, secure identifier generation, JWT time-claim inspection, safe raster preview, and file export also run locally.

The SQL formatter uses a disposable browser worker and never executes a query or connects to a database. SQL input is limited and time-bounded to protect browser responsiveness; input and output are not placed in the URL or browser storage. A successful format is a presentation result, not proof that a query is valid, safe, authorized, or correct.

The YAML formatter, syntax validator, tree viewer, YAML-to-JSON converter, and JSON-to-YAML converter use a disposable browser worker. YAML and JSON source is limited to 200,000 UTF-16 code units; YAML parsing also enforces bounded node, nesting-depth, diagnostic, viewer-row, and output sizes, plus a two-second operation limit. YAML-to-JSON additionally bounds alias construction to a maximum alias count of 50 per YAML document, rejects cycles and unsupported mapping keys or tags, and does not apply YAML 1.1 merge-key expansion. These checks protect browser responsiveness and make conversion policy explicit; they do not validate Kubernetes, Compose, CI, or another application's schema.

The XML formatter, well-formedness validator, and tree viewer also use a disposable browser worker. They do not retrieve external DTD files, XSD files, or other schemas. The formatter can preserve, and the tree viewer can display, a bounded DOCTYPE as opaque source text without fetching or validating its DTD. A DOCTYPE stops the validator because DTD grammar is unsupported. Custom ENTITY declarations and undefined named references are rejected before parsing. The validator checks XML 1.0 document syntax and namespace constraints only; it does not establish validity against a DTD or XML Schema.

The UUID generators, validator, and decoder use page memory and browser cryptography without sending UUID or GUID text to LiveParse. Decoding only interprets fields already present in an identifier; it cannot recover an original name or prove where an identifier came from. UUID v1 and v6 can expose an encoded timestamp and node value, while UUID v7 exposes its encoded Unix-millisecond time. Treat those fields as potentially identifying metadata, and do not treat a UUID as a password, access token, or other secret credential.

The hash and checksum tools encode text as UTF-8 or read the exact bytes of a selected local file, then calculate MD5 or a SHA-2 digest in page memory. Text is limited to 5,000,000 UTF-16 code units and files to 64 MiB because browser digest APIs buffer the complete input. The selected file, pasted text, calculated digest, and expected checksum are not uploaded. A digest match does not authenticate the publisher of a file, MD5 is not collision-resistant, and fast general-purpose hashes are not password-storage schemes.

The URL encoder, decoder, parser, and query-string parser keep supplied text and generated results in page memory. The decoder performs exactly one strict decoding round and rejects malformed percent escapes, invalid percent-encoded UTF-8, and unpaired UTF-16 surrogates instead of silently repairing them. The URL and query parsers apply the same strict text checks before invoking the browser's WHATWG URL or URLSearchParams implementation. The URL parser may normalize its serialized result; its component view redacts credential values and its copy actions remove URL userinfo, but the original input remains visible until cleared. LiveParse does not open, navigate to, fetch, or execute a parsed address. The query parser follows form-query rules, where + represents a space, and preserves ordered duplicate and blank fields in its pair output; its rebuilt query is a canonical form serialization rather than the original spelling. General encoder, decoder, and query input is limited to 200,000 UTF-16 code units, URL and optional base input to 32,768 code units each, and parsed output to 10,000 non-empty query fields.

The JWT tools do not put the compact token in the page URL or browser storage and do not request token-supplied key or certificate addresses such as jku or x5u. Their downloadable decoded report omits the original compact token. A bearer token may nevertheless grant real access, so prefer synthetic or redacted data, clear the input after use, and follow your credential revocation process if a token is exposed.

Your input remains in page memory until you replace it, reload the page, or close the tab. A browser extension, clipboard manager, screen-sharing session, or managed device may have access outside LiveParse's control. Remove secrets and personal data when your organization requires it.

2. Website delivery and security data

When you visit any website, the hosting and network providers necessarily receive connection information such as an IP address, requested URL, time, user agent, and security signals. LiveParse uses this information only to deliver files, prevent abuse, diagnose availability, and secure the service. The current application has no user accounts and does not combine connection information with the tool data you provide.

To measure progress toward search visibility without a client-side analytics script, the primary LiveParse server recognizes common search-engine referrer hostnames and filters obvious automated user agents at request time. It stores only daily aggregate counts by search engine and landing-page path. It does not store an IP address, user agent, full referrer URL, search query, or per-visit timestamp in this aggregate, and it sets no identifier for this purpose. These counts measure search landing visits, not unique people or Search Console clicks.

The primary server also records an hourly process-heartbeat bucket and daily aggregate counts when a canonical HTML request's User-Agent claims to be a named search crawler. This aggregate stores only the claimed crawler category and canonical page path; it does not store an IP address, raw User-Agent, referrer, query, or individual request time. User-Agent text can be spoofed, so these counts are explicitly unverified crawler claims rather than authenticated Googlebot or Bingbot identities. The heartbeat observes the local server process, not end-to-end internet availability.

Infrastructure providers may retain limited request or security records under their own operational policies. LiveParse does not promise a specific provider retention period that it cannot control.

3. Cookies and browser storage

LiveParse currently sets no analytics or advertising cookies and does not use local storage to retain tool input. Hosting or security infrastructure may use a strictly necessary cookie when needed to protect or deliver the site. Blocking such a cookie may affect access but does not cause your pasted or selected data to be uploaded.

Because no optional cookie category is currently active, LiveParse does not show a consent banner. If analytics or advertising is introduced, optional scripts will remain blocked until any legally required consent mechanism is available, and this notice will name the provider and purposes first.

4. Advertising and affiliate disclosure

No ad network, product carousel, sponsored placement, or affiliate link is currently loaded by LiveParse. Older versions displayed a third-party retail widget on the English developer page; that integration has been removed. LiveParse will not reactivate it merely by changing the security policy.

If monetization is added later, LiveParse will select the provider, publish the relevant disclosure, use an appropriate consent platform where required, and load the integration only after those controls are in place. Paid or affiliate content will be labeled near the placement.

5. Your choices and requests

You can avoid entering tool data entirely and still read the static guides. You can clear tool input by reloading or closing the tab. For a privacy question, correction, or deletion request concerning data LiveParse controls, contact the creator through the LiveParse GitHub issue tracker. Do not post secrets or personal data in a public issue.

6. Changes to this notice

This page will be updated before materially different data collection, analytics, advertising, or affiliate processing begins. The effective date above identifies the current version.