Legal

Privacy Policy

Last updated: September 17, 2026

DevDesignKit (“we”, “us”, or “our”) is a collection of browser-based utilities, cheat sheets, and code snippets operated by Peter, an individual developer based in the United States. This policy is split into two parts so the two parties are never mixed up: what the website itself does with your data (Part 1), and how third-party advertising (Google AdSense) may use cookies and personal data (Part 2).

Part 1: First party: how this website handles your data

Everything runs in your browser (zero uploads). The site is a 100% client-side application built with React, TypeScript, and Vite, served as static files. Every tool: JSON formatting, encoding, regex testing, image conversion, and the rest: processes your input in your browser's memory. There is no backend, no server round-trip, and no third-party processor that ever receives the content you work with.

We do not collect personal information. The site requires no account or login, and there are no forms that transmit data to a server. The only contact method is a direct mailto: link that opens your own email client.

We do not sell personal information. We do not sell, rent, or share personal information with anyone, because we do not hold any.

What we store locally (localStorage only). The site uses the browser's localStorage for one purpose:

  • ddk-theme: remembers your dark or light theme preference.

Google Funding Choices is loaded for the applicable European Economic Area (EEA), United Kingdom, Switzerland, and US privacy messages, while this build keeps advertising paused. Before advertising is enabled, the messages must be published and verified in AdSense; any consent choice is stored by Google, not in this site's local storage. Use the Privacy choices link in the footer to reopen or withdraw your choice.

This value never leaves your device. You can clear it at any time by clearing your browser's site data.

Because every tool executes inside this page’s JavaScript context, the text you paste or the image you drop into a converter lives only in the memory of that tab. It is not serialised for transmission, written to a server log, or handed to a remote service for further work. Browser-native capabilities such as the Web Crypto API run their primitives entirely on the local device, so even encoding or hashing operations never require a round trip to a server. Static hosting reinforces the same boundary from the other side. The server sends the application code once, over HTTPS, and every keystroke after that stays on your machine, where the browser already holds it.

Watch the Network panel for yourself. No upload request ever leaves the tab.

Part 2: Third party: Google AdSense advertising

Advertising cookies. When enabled, DevDesignKit may display advertising served by Google AdSense; the current build keeps advertising paused while consent controls are configured. Google and its advertising partners may use cookies and similar technologies to serve ads based on your prior visits to this and other websites, and to measure ad performance. This may involve the processing of personal data such as a cookie identifier or an advertising identifier.

Consent is required. Under the GDPR, the CCPA and similar laws, personalized advertising requires your consent. If a consent message is displayed, you can accept or reject advertising cookies through it; if you reject, advertising cookies are not used for personalization and the ads you see are not personalized. You can also review or change your advertising choices at any time in Google Ads Settings.

How to opt out. You can opt out of personalized advertising through Google's Ads Settings at adssettings.google.com and through the industry opt-out tools at aboutads.info. Google's use of cookies is described in the Google Privacy & Terms page.

Cookies are stored by the browser and attributed to the domain that sets them, which is a model defined in the HTML standard’s storage and origin rules. A cookie set by an advertising network is a third-party cookie from the perspective of this site, and the two stores are kept apart by the browser. The first party cannot read the values Google writes, and Google cannot see the content being processed inside a tool area. That separation is why this policy addresses the two parties in two parts, each with its own consent and opt-out path.

Your privacy rights (GDPR and CCPA)

Depending on where you live, you may have rights under the EU GDPR, the CCPA, and similar laws, including the rights to access, correct, delete, or port personal data and to object to or opt out of certain processing. Because the first party does not collect personal data, there is usually nothing for us to access or delete on your behalf. For data processed by Google through advertising, you can exercise your rights through Google's tools.

Data security

Since your inputs never leave your device, the primary security boundary is your own browser and operating system. Keep your browser up to date and avoid using these tools on shared or untrusted devices when handling sensitive material. Updates matter because browser vendors patch the same rendering and storage engines these tools run on, so a current browser closes issues that an older one still exposes. The site is served over HTTPS, so the static application code is delivered over an encrypted connection.

HTTPS encrypts the connection between the browser and the static host, which protects the application code and assets while they are in transit. Transport encryption matters on a site like this one because it keeps the code you download from being modified or read in between. It does not need to protect your inputs, because those never travel over the wire at all. RFC 9110 describes the request semantics behind a normal page load: a GET request for a resource, with no upload endpoint attached. That combination, an encrypted delivery channel and a client-side execution model, is what makes the local-processing claim something you can verify yourself without leaving the page.

That boundary is the whole design, and nothing else needs attention.

Children's privacy

The site is a general-audience developer and designer toolkit and is not directed at children under 13. Because we do not collect personal information, we also do not knowingly collect information from children.

Changes to this policy

We may update this Privacy Policy from time to time. The “Last updated” date at the top of this page indicates when the current version took effect.

Contact us

Questions about this policy should be sent to ndeyekhadymbodj91@gmail.com.

You may also wish to review our Terms of Service.

The client-side processing references behind this policy

Browser-native cryptography is what makes a statement like "processed locally" technically concrete. The Web Crypto API runs its primitives on the device, so a tool that needs encoding or hashing never has to hand data to a server. That reference is what supports the zero-upload claim in Part 1, and it can be checked directly in the browser's developer tools, because the API is implemented by the browser itself with no external service involved.

The readability expectations this policy is written against come from the W3C WCAG 2.2 recommendations, which set out the text spacing, contrast, and presentation guidance that keep a legal page legible for every reader. The same guidance informs the text size and spacing used on this page, and it explains why this policy avoids decorative styling that would hurt readability.

RFC 9110 defines the HTTP semantics behind the statement that this site has no upload endpoint. A normal page load is a GET request for a static resource, and nothing in the site’s request handling accepts uploaded content. The reference pins down exactly which parts of the protocol the description relies on.