Remove This Application Was - Created By A Google Apps Script User Updated

There is no direct "off" switch to remove the "This application was created by a Google Apps Script user" banner from a standard web app, as it is a built-in security measure by Google

. However, you can bypass or hide it using several workarounds depending on your environment. 1. Embed the Web App in an Iframe

The most common way to hide the banner is to host your own HTML page (on GitHub Pages, for example) and embed the Apps Script web app URL inside an "YOUR_WEB_APP_URL" "width:100%; height:100vh; border:none;" Use code with caution. Copied to clipboard : Ensure your script allows iframing by setting the XFrameOptionsMode javascript HtmlService.createHtmlOutputFromFile(

) .setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL); } Use code with caution. Copied to clipboard 2. Publish as a Workspace Add-on If you publish your script as a verified Google Workspace Add-on

, the warning banner typically does not appear. This requires more development work and often a verified Google Cloud project, but it is the "official" way to remove such warnings for professional applications. 3. Use within the Same Workspace Domain There is no direct "off" switch to remove

If you are part of a Google Workspace organization, the banner is

to other users within the same domain. If your intended audience is internal to your company or school, simply deploying it to your organization will solve the issue. 4. Client-Side Browser Extensions (For Personal Use)

If you only want to hide the banner for yourself, you can use browser extensions like uBlock Origin

or a custom CSS injector to set the warning element's display to CSS Selector #warning display: none !important; GitHub Pages site to host the iframe for your application? AI responses may include mistakes. Learn more Enabling OAuth consent for internal users only

✅ Option 1: Publish as a Google Workspace Add-on (internal use only)

If your app is for internal company use (within a Google Workspace organization), you can suppress the warning by:

1. Enabling OAuth consent for internal users only.
2. Setting the app’s publishing status to “Testing” but adding your domain as trusted.

This won’t fully remove the line, but it changes it to:

This application was created by [your domain]

Steps:

• Go to Google Cloud Console
• Select your project
• Go to APIs & Services > OAuth consent screen
• Choose Internal (not External)
• Fill in your app name and domain
• Publish the app (no verification needed for internal)

Myth 2: Publishing to the Google Workspace Marketplace removes it

Partially true. If your app is listed on the Marketplace and verified, the warning disappears. However, listing requires verification and typically a security assessment.

Part 1: Why Does the “Created by a Google Apps Script User” Warning Appear?

Before removing the warning, you must understand its origin. Google introduced this security measure to protect users from malicious or poorly configured third-party applications that request access to their Google Drive, Gmail, Sheets, or other sensitive data.

When you create an Apps Script project and deploy it as a web app or an add-on, Google automatically classifies it as an unverified app unless you meet specific criteria.

Part 3: Method 1 – Removing the Message for Internal Users (Domain-Wide Trust)

This is the fastest way to get rid of the warning for company tools. It does not require Google’s security review. This won’t fully remove the line, but it changes it to:

3.2 Modifying google.script.run Responses

Attempting to intercept and strip the footer from server responses is impractical because the footer is not part of the user’s returned HTML—it is appended by Google’s serving layer outside the developer’s control.

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.