How to protect your HTML page from being copied or edited

You made an HTML page, perhaps a calculator, a game, or a deliverable for a client, and you're about to send or publish it. You don't want it copied, and you don't want it changed. Start with what no tool can do: a page a person can open is a page that person can read, code included. This guide shows why, says what each popular trick does and doesn't do, and then covers the 4 things that hold up. The browser and vendor pages quoted here were read on November 15, 2026.

Already have the HTML file? Drop it into the upload box at the top of this page, or paste its code, for a preview link without an account. That preview link has no password. Click Keep this page — free, no card and sign up, and the page moves into your account, where you choose who can open it as you publish, as in the steps below.

Why HTML can't be hidden

A browser shows a page by downloading its HTML, CSS, and JavaScript and running them on the visitor's device. The code is on their computer before they see anything, and every browser has built-in ways to display it.

• View Source. Google's list of Chrome shortcuts has one to “Display non-editable HTML source code for the current page”: Ctrl + u on Windows and Linux, ⌘ + Option + u on a Mac.
• Developer tools. MDN says: “Your browser's devtools show you the current state of the code rendered in your browser to create the webpage you can see.” Chrome's shortcut list gives F12 or Ctrl + Shift + j to open them on Windows and Linux.
• Every file the page loaded. In Chrome's Sources panel, “Click the Page tab to view all of the resources that the page has loaded”, and “You can view any type of file.”

None of these needs the right-click menu, an extension, or any skill. A page that reaches a visitor's screen has already given them its code.

What each method stops

Protecting HTML from being copied

Blocking right-click. A script can cancel the contextmenu event. In MDN's example, the paragraph with the script “will do nothing when right-clicked”. That's all it does. The keyboard shortcuts above still open the source, and MDN notes that in Firefox, “if the user holds down the Shift key while right-clicking, then the context menu will be shown without a contextmenu event being fired.” It protects nothing, and it takes the menu away from every honest visitor too.

Blocking text selection. MDN: “The user-select CSS property controls whether the user can select text.” With none, “The text of the element and its sub-elements is not selectable.” The text stays in the page's source, one shortcut away. A visitor who wants to copy your phone number can't.

Minifying. MDN defines minification as “removing unnecessary or redundant data without affecting how a resource is processed by the browser”, used “to improve web performance by reducing file size.” It isn't protection: MDN adds that “developer tools have 'prettification' features that can add white space back into the code”, and Chrome's docs say “By default, the Sources panel pretty-prints minified files.”

Obfuscating. An obfuscator rewrites JavaScript so it's hard for a person to follow. The script still has to run in the visitor's browser, so all of it is still delivered. The README of javascript-obfuscator, a free open-source tool, warns that “the obfuscated code is 15-80% slower (depends on options) and the files are significantly larger”, and its own comparison table rates the free package “fully vulnerable” to analysis by an AI model. Obfuscation doesn't touch your HTML, your text, or your images.

What that leaves:

• Put nothing in the page you can't afford to lose. Keys and the logic people pay for belong on a server, as the section below explains.
• Limit who can open the page. A copier has to reach it first.
• Say whose it is. A copyright line and a licence stop no download, but they're what you point to afterwards.

Protecting an HTML file from being edited

A file you send is the recipient's copy. Any text editor opens it, and whatever they change, they can save and pass on as yours. No setting inside the file prevents that.

A published link is different. The page lives at your address, and visitors get a fresh copy from it each time.

• A visitor's edits stay on their screen. The developer tools let anyone change a page they're viewing. MDN: “You can make any changes you want, but you cannot save your changes.” Chrome's docs: “DevTools erases your CSS and JavaScript changes when you reload the page.” Nobody else sees them.
• Only you change what's at the link. On Convika, a new version goes live from your account: Upload as a new version, then Publish v2 at the same link. Everyone who has the link gets the new page. How to update an AI-made page at the same address has the steps.
• The link is the reference. If someone shows you an edited screenshot or a changed file, the page at your address says what you published.

For a client's sign-off on a draft, see how to collect their feedback and confirm the changes.

Limit who can open the page

This is the protection that works, because it happens before the code is sent.

• A password a server checks. On Convika Pro, you choose Only people with the password as you publish. Convika checks the password on its server before sending the page. When Convika tested this on October 13, 2026, the password screen returned a 401 status, and the response held neither the page's title nor any of its text. After the right password, the browser asks again only after 30 days without opening the page. A new password locks everyone out again. How to password protect an HTML page has the full test and what visitors see.
• A private link. On Convika, choose Private link (Pro) when you publish—anyone with the link can open the page without a password or account, while Convika tells search engines to keep it out of their results and leaves it out of the sitemap (step up to Only people with the password if the link might get forwarded). The free Public choice may show up in search results and in Convika's gallery.
• No frames on other sites. A Convika page refuses to be shown in a frame on another site, so nobody can display your live page inside theirs.

Know the limit. Everyone you give the password to can still open View Source and save the page. A password decides who gets the code, not what they do with it. So give it to people you'd hand the file to.

A password typed into the page's own JavaScript is not this. The password and the content it hides both sit in the source: why a JavaScript password doesn't protect the page.

Publish the page for the people you choose in 4 steps

Convika serves one .html or .htm file up to 2 MB, or pasted code, at a lasting link, with its HTML, CSS, and JavaScript as they are. It doesn't minify or obfuscate your code, and it runs no server code.

1. Get a preview link

Drop the file into the upload box at the top of this page, or paste the code, and click Get my preview link. You get a link in seconds, without an account. It works for 3 minutes, with scripts and forms off, so it's for checking the layout. It has no password.

2. Keep the page

Click Keep this page — free, no card and sign up. The page moves into your account, and its scripts run in the dashboard preview.

3. Choose who can open it

Click Publish page. Under Who can open this page?, choose Only people with the password. Type a password of 8 to 128 characters and click Next. Passwords come with Pro, so the first time you publish, Convika shows an order for Pro monthly ($12 a month). Click Subscribe for $12/month and pay on the next screen. The page goes live behind the password once the payment goes through, at an address like yourpage.convika.page.

To publish without paying, choose Public and click Next, then, the first time, click Publish free. A Public page opens for anyone with the link, and it may show up in search results and in Convika's gallery.

4. Send the link and the password separately

Send the link in one message and the password in another. Anyone who opens only the link sees the password screen.

Keys and paid logic

Anything in the page is in the visitor's hands, so a secret can't live there. This matters most for pages an AI chat wrote: they often carry an API key in the script.

• API keys. Google Cloud's guidance is “Don't include API keys in client code or commit them to code repositories”, because keys in the source “are open to interception or theft by bad actors. The client should pass requests to the server, which can add the credential and issue the request.” Stripe's docs say “Only publishable keys are safe to expose outside your application's back end.”
• The logic people pay for. A pricing formula, a scoring model, or the answers to a paid quiz can be read from the script if the browser runs it. MDN: “Server-side programming allows sites to restrict access to authorized users and serve only the information that a user is permitted to see.”

Before you publish, search the file for key, token, and secret. If the page needs one to work, it needs a backend. Convika isn't that backend: it runs no server code, and a script on a Convika page reaches only the page's own address. Host that part on a service that runs your code, and keep the page for what a visitor may see.

Legal protection

This section repeats what the U.S. Copyright Office says. It isn't legal advice, and other countries have their own rules.

The Office's FAQ says “Your work is under copyright protection the moment it is created and fixed in a tangible form”, and that “The original authorship appearing on a website may be protected by copyright. This includes writings, artwork, photographs, and other forms of authorship protected by copyright.” It also says what copyright leaves out: “Copyright does not protect ideas, concepts, systems, or methods of doing something.”

Registration “is voluntary”, but “You will have to register, however, if you wish to bring a lawsuit for infringement of a U.S. work.” The owner can also “authorize others to exercise these exclusive rights”: that's what a licence line on your page does.

If an AI tool wrote the page, read the Office's Copyright and Artificial Intelligence page first: Part 2 of its report “addresses the copyrightability of outputs created using generative AI.” For a dispute, ask a lawyer.

Frequently asked questions

How do I protect my HTML code from being copied?

You can't stop someone who can open the page: the browser downloads the code, and View Source shows it. Limit who can open it instead, with a password a server checks or a private link. Keep API keys and paid logic on a server, where they're never sent to the browser. Blocking right-click, minifying, and obfuscating don't stop a copy.

Can I hide the source code of a web page?

No. A browser can't show a page without receiving its HTML, CSS, and JavaScript. Chrome has a shortcut to “Display non-editable HTML source code for the current page”, and its Sources panel lists “all of the resources that the page has loaded”. Only code that stays on a server is hidden.

Does disabling right-click protect a website?

No. A script that cancels the contextmenu event hides the menu on the elements it covers. View Source and the developer tools still open from the keyboard, and MDN notes that Firefox shows the menu anyway when the visitor holds Shift. It also removes the menu for visitors who meant no harm.

Does minifying or obfuscating code stop people from copying it?

No. Minifying makes the file smaller, and Chrome's Sources panel “pretty-prints minified files” by default. Obfuscating makes JavaScript harder to read, but the script still runs in the visitor's browser, and javascript-obfuscator's README says obfuscated code is “15-80% slower”. Neither hides your HTML, text, or images.

How do I protect an HTML file from editing?

Don't send the file. A file you send is the recipient's copy, and any text editor changes it. Publish the page and send its link: visitors can edit only what's on their own screen, and Chrome's docs say those changes are erased “when you reload the page.” Only you can put a new version at the link.

Can I make an HTML file read-only?

Not in a way that survives sending it. Once someone has the file, they hold a copy they can change and save. To keep one version that only you change, publish the page at a link. For a record nobody should alter, send a PDF beside the link.

Can I password protect an HTML page?

Yes, when a server checks the password before it sends the page. A password written into the page's JavaScript sits in the source. On Convika Pro ($12 a month), choose Only people with the password as you publish. How to password protect an HTML page compares the other ways.

How do I hide an API key in HTML?

You can't. Anything in the page reaches the visitor's browser. Google Cloud's guidance is “Don't include API keys in client code”, and to have the client “pass requests to the server, which can add the credential and issue the request.” Move the call to a backend, and delete any key that was already published.

Is my HTML page protected by copyright?

The U.S. Copyright Office says “The original authorship appearing on a website may be protected by copyright”, from “the moment it is created and fixed in a tangible form”. It doesn't protect “ideas, concepts, systems, or methods of doing something.” Registration is voluntary, but needed to sue over a U.S. work. This isn't legal advice.

Sources

• Chrome keyboard shortcuts (Google Chrome Help) (no date on the page; read on November 15, 2026)
• What are browser developer tools? (MDN) (last modified November 2, 2026; read on November 15, 2026)
• Sources panel overview (Chrome DevTools) (last updated September 27, 2024) and Debug JavaScript reference: Make a minified file readable (Chrome DevTools); read on November 15, 2026
• Element: contextmenu event (MDN) (last modified October 26, 2026; read on November 15, 2026)
• user-select CSS property (MDN) (last modified April 20, 2026; read on November 15, 2026)
• Minification (MDN Glossary) (last modified July 11, 2025; read on November 15, 2026)
• javascript-obfuscator README (GitHub) (read on November 15, 2026)
• Introduction to the server side (MDN) (last modified September 12, 2026; read on November 15, 2026)
• Best practices for managing API keys (Google Cloud) (last updated November 13, 2026; read on November 15, 2026)
• API keys (Stripe Docs) (read on November 15, 2026)
• Copyright in General, What Does Copyright Protect?, What is Copyright?, and Copyright and Artificial Intelligence (U.S. Copyright Office; read on November 15, 2026)