Our security approach
Where possible, we design our tools to minimize data exposure and reduce the platform's overall attack surface. Practices we follow include:
- Processing supported inputs locally in the browser, without a server-side conversion API.
- Validating file size, extension, MIME type, and parser compatibility before processing begins.
- Sanitizing HTML output before it is rendered in preview.
- Rejecting XML external entity and DOCTYPE declarations to mitigate XXE-style risks.
- Displaying generated code and schemas for review rather than executing them within the application.
- Applying reasonable bounds on large inputs and computationally expensive operations.
- Omitting source maps from production builds and applying browser security-header rules on supported hosting platforms.
- Locking and auditing dependencies as part of our development process.
Reporting a vulnerability
If you believe you've found a security vulnerability, we'd appreciate the opportunity to investigate and address it. Please send a clear, concise report to info.codingvila@gmail.com including the affected URL, a description of the potential impact, clear steps to reproduce the issue, and, where applicable, a non-destructive proof of concept. To help us investigate safely and fairly, please do not access or modify another person's data, attempt to degrade the availability of the service, or disclose a vulnerability publicly before we've had a reasonable opportunity to review and address it.
Scope and response expectations
We do not currently operate a formal bug bounty program, and we are not able to guarantee a specific response time or offer a reward for reports. That said, we genuinely value well-documented, good-faith, non-destructive reports, and we review them as our availability allows. We will make a reasonable effort to acknowledge valid reports and keep the reporter informed as an issue is investigated.
Deployment protections
Our production build includes configuration for a content security policy, anti-framing protection, MIME-sniffing prevention, restricted browser permissions, referrer privacy controls, cross-origin isolation, and HTTPS enforcement. These protections depend on our hosting provider correctly applying and preserving the associated response headers; we review this configuration periodically to help ensure it remains in effect.
Understanding client-side limits
Processing data locally in your browser reduces server-side exposure, but it cannot protect against every risk. It does not, for example, protect a compromised browser, a malicious or misconfigured extension, an insecure device, or the operating system's clipboard. It's also worth understanding that, like any browser-based application, the HTML, CSS, and JavaScript delivered to your browser can be inspected by anyone using the site; minification and the omission of source maps reduce the convenience of doing so but do not make client-side code secret or inherently protected. We recommend keeping your browser and operating system up to date, and avoiding the processing of highly sensitive secrets on shared or otherwise untrusted devices.
Related information
For details on how we handle data more broadly, including tool input and third-party advertising, please see our Privacy Policy and Cookie Policy. General accuracy and reliability limitations are described in our Disclaimer.
Last updated: 16 August 2026.