Remove This Application Was Created By A Google Apps Script User -
To remove the "This application was created by a Google Apps Script user" banner from your web app, you generally need to change how the script is hosted or verified, as it is a built-in security feature for unverified scripts. Primary Solutions
Embed in a Google Site: The banner is typically hidden when the web app is embedded within a Google Site or another website.
Use a Google Workspace Account: If the script and the users are within the same Google Workspace domain, the banner does not appear.
Deploy as a Google Workspace Add-on: Building and publishing your project as an Editor Add-on will remove this specific web app banner.
Link to a Standard GCP Project: Instead of the default project, create a new Google Cloud (GCP) project, associate it with your script, and go through the official OAuth verification process. Client-Side Workarounds (Developer/Internal Use)
These do not remove the banner for other users but can hide it on your own browser:
Browser Extensions: Use extensions like uBlock Origin or Custom JavaScript for websites to inject code that hides the warning element.
JavaScript Injection: For internal displays, you can use a script to set the banner's display style to none: javascript
document.getElementById('warning').style.display = 'none'; ``` Use code with caution. Copied to clipboard
How to Remove the "This application was created by a Google Apps Script user" Header
If you have ever built a web app using Google Apps Script (GAS), you have likely encountered the persistent gray banner at the top of the page that reads: "This application was created by a Google Apps Script user." To remove the "This application was created by
While Google includes this for security and transparency—to ensure users know they aren't interacting with an official Google product—it can be a major eyesore for developers trying to create a professional, branded experience.
In this guide, we will explore the reality of this disclaimer and the best ways to work around it. Can You Directly Remove the Banner?
The short answer is no. There is no "off switch" in the Google Apps Script settings to hide this banner.
Because the web app is hosted on the ://google.com domain, Google injects this iframe header as a security measure to prevent phishing and spoofing. Even with a Google Workspace (formerly G Suite) Business or Enterprise account, the banner remains.
However, depending on your technical skills and how you intend to share the app, there are three primary workarounds. Method 1: Embedding the Web App in an Iframe
The most common way to "mask" the Apps Script environment is to embed your Google Apps Script URL into your own personal or business website.
Deploy your Script: In the Apps Script editor, click Deploy > New Deployment. Select Web App and set "Who has access" to Anyone. Copy the Web App URL: It will look like https://google.com.
Embed on your Site: Use the following HTML code on your own website:
Use code with caution.
The Result: While the banner still technically exists inside the iframe, it stays contained within that frame. If you style your website correctly, the banner feels less like a "system warning" and more like a small footer or header element within a specific window. Method 2: Using a Custom Domain with a Proxy (Advanced) If the Application is a Google Apps Script Project
If you want to completely strip the banner, you cannot host the app on Google’s servers directly. Instead, you can use a "proxy" or a middle-man server.
Using a service like Cloudflare Workers or a simple Node.js/Express server, you can fetch the HTML content from your Google Apps Script, strip out the Google-injected header tags, and serve the cleaned HTML on your own custom domain. Pros: Complete removal of the banner; professional URL.
Cons: Requires significant coding knowledge; may violate Google’s Terms of Service regarding masking the origin of the script.
Method 3: Switching to Google Cloud Run (The Professional Path)
If the "Created by a Google Apps Script user" banner is a dealbreaker for a professional project, it may be time to move beyond Apps Script.
Google Apps Script is designed for quick internal tools. For client-facing applications, developers often migrate their logic to Google Cloud Run or Firebase Hosting.
Cloud Run: Allows you to run code in any language (Python, Node.js, Go) without any forced headers.
No Disclaimers: Since you are hosting the environment, Google does not inject any security banners. Why Does Google Put It There?
It is important to remember why this exists. Google Apps Script allows anyone to write code that can access Google Drive, Gmail, and Calendar data. Without that banner, a malicious actor could easily build a fake "Google Login" page that looks identical to a real one. The banner serves as a "Proceed with Caution" sign for the end-user.
To summarize your options for dealing with the "This application was created by a Google Apps Script user" message: Check the Script's UI Settings : If you're
Accept it: For internal company tools, it is rarely an issue.
Iframe it: Embed it into your own site to make it feel like part of a larger dashboard.
Migrate: If branding is paramount, move your project to a dedicated hosting platform like Firebase or Vercel.
By understanding these limitations, you can better plan your project's user experience from the start.
If the Application is a Google Apps Script Project
-
Check the Script's UI Settings: If you're using a custom UI (like an HTML service), ensure that the notice isn't hardcoded into the HTML or the script's interface settings.
-
Review Script Properties and Settings: Sometimes, Google Apps Script projects have project properties or settings that could be influencing the display of such notices. Make sure there's no setting or property that you're overlooking.
Practical considerations and caveats
- Verification time and effort: OAuth verification can take days and sometimes requires proof of domain ownership, a privacy policy, and videos/demo of the app’s use. Plan ahead.
- Scopes drive scrutiny: The more powerful the API scopes, the more likely Google will require verification and will display prominent branding once approved.
- Internal vs external users: If your app is strictly internal to a Google Workspace organization, set deployment to internal to avoid the external “user” label without full public verification.
- No guaranteed instantaneous change: Some UI elements may cache or take time to update after verification or branding changes.
- Respect user privacy and transparency: Even when branding is polished, keep consent screens clear about the scopes you request and why.
Part 2: Who Can Remove the Warning? (Ownership & Account Types)
Not everyone can remove this warning. Your ability depends on the type of Google account you are using.
| Account Type | Can Remove Warning? | Notes | | --- | --- | --- | | Personal Gmail (@gmail.com) | ❌ No | You cannot complete verification. The warning will always appear for external users. | | Google Workspace Individual | ❌ No | Same restrictions as personal Gmail. | | Google Workspace Business / Enterprise | ✅ Yes | Domain admins can verify apps for internal use or public distribution. | | Google Cloud Platform (GCP) Project | ✅ Yes | Any account (including personal) can verify, but personal accounts rarely succeed unless you register a business. |
Key takeaway: If you are using a free @gmail.com account to share an Apps Script web app with the public, you cannot remove the warning. You must upgrade to a Google Workspace account or migrate the project to a GCP project under a verified domain.
