A favicon is a small asset, but it plays a real role in how customers recognize your SuiteCommerce storefront. It appears in browser tabs, bookmarks, browsing history, mobile shortcuts, and some search experiences. When the icon is missing, outdated, or replaced with a generic default, the storefront feels unfinished even when the rest of the customer experience is polished.
Adding a custom favicon to SuiteCommerce is straightforward when the storefront uses a supported configuration field. It requires more care when the site runs a customized SuiteCommerce Advanced implementation or a heavily modified theme. In those cases, the favicon needs to be added through the correct theme or extension workflow, then deployed and tested across browsers and devices.
This guide explains how we approach the process, where the favicon belongs, which implementation path to choose, and how to troubleshoot the most common issues.
Why the SuiteCommerce favicon matters
A favicon does more than decorate a browser tab. It reinforces brand recognition when customers have multiple tabs open, return to a saved bookmark, or browse their history. For B2B buyers who work with multiple suppliers and purchasing portals, a recognizable icon makes the correct storefront easier to identify.
It also contributes to perceived quality. Customers rarely complain that a favicon is missing, but they notice the accumulated details that make a digital storefront look trusted and complete. A generic icon, a broken image, or an icon that still shows a previous brand creates unnecessary friction.
The favicon should support the wider design system. Its colors should remain legible at a small size, its shape should work against light and dark browser interfaces, and it should remain recognizable when reduced to a tiny square.
A favicon is not a substitute for good SuiteCommerce design, performance, or navigation. It is one small part of a broader storefront experience. We cover that wider perspective in our article on how SuiteCommerce becomes a real B2B growth engine.
Choose the right implementation path first
Before editing code, identify which type of SuiteCommerce implementation your business operates.
The correct path depends on whether the favicon is available through your site configuration, whether the storefront uses a modern extension-based architecture, or whether the site relies on a customized SuiteCommerce Advanced source code project.
| Storefront situation | Recommended approach |
|---|---|
| Your SuiteCommerce version exposes a favicon or site icon field | Upload the asset through the supported configuration interface |
| Your site uses a modern theme and extension workflow | Add the favicon through the theme or a small custom extension |
| Your site uses SuiteCommerce Advanced | Add the asset and markup through the source-controlled theme or extension structure |
| Your site has a custom deployment process | Follow the existing source control, build, and release workflow |
| You are unsure which implementation applies | Confirm the version and deployment model before making changes |
This distinction matters because a direct edit in a generated or managed file can disappear during the next bundle, theme update, or deployment. A favicon change should be small, but it still belongs in the same controlled process as other storefront customizations.
If your team needs help reviewing the implementation, our NetSuite Development Services support SuiteCommerce customization, storefront integrations, and maintainable NetSuite development work.
Prepare the favicon asset
Start with the image itself. The strongest favicon is simple, high contrast, and recognizable without relying on small text. A detailed logo that looks good in a large header often becomes unreadable at favicon size.
Use a square source image and create the formats your storefront and browser support require. An ICO file remains widely compatible, while PNG files provide clean results and work well in current browsers. SVG can be useful for scalable browser support, but its handling depends on the storefront implementation and browser context, so it should not be the only format unless your compatibility requirements support that choice.
A practical asset package includes:
A 16 by 16 or 32 by 32 pixel ICO or PNG version for browser tabs.
A larger PNG version, such as 180 by 180 pixels, for Apple touch icons when mobile bookmarks matter.
A 192 by 192 or 512 by 512 pixel PNG version if the storefront supports installation or home-screen use.
A version with transparent or carefully selected background treatment so the mark remains visible in different browser themes.
Keep the file names descriptive and stable. Names such as `favicon.ico`, `favicon-32.png`, and `apple-touch-icon.png` are easier to identify than names generated by a design application. Avoid replacing a file with a different format while keeping a misleading extension. Browsers and CDNs interpret file headers and content types inconsistently when the extension and actual file format do not match.
Before uploading the asset, test it at small sizes. Place it on both a light and dark background, remove unnecessary wording, and confirm that the primary brand mark remains recognizable.
Method one: use the supported SuiteCommerce configuration
Some SuiteCommerce implementations provide a configuration option for the storefront icon or favicon. The exact label and location depend on the SuiteCommerce version, account configuration, and active theme.
When that setting exists, it is the preferred approach because the platform manages the asset reference through the supported site configuration rather than requiring a template modification. It also reduces the risk that a code deployment overwrites the change.
The general process is to open the relevant Commerce website or SuiteCommerce configuration record, locate the branding or site identity settings, upload the approved favicon asset, save the configuration, and publish the change according to the account’s normal release process.
Do not assume that saving a configuration record makes the live site change immediately. SuiteCommerce storefronts frequently use published configurations, compiled assets, CDN layers, or browser caching. Confirm how your account promotes configuration changes between development, preview, and production environments.
This path is best when:
The configuration field is available in your SuiteCommerce version.
The asset applies consistently to the storefront.
You do not need page-specific icons or advanced conditional behavior.
Your team wants a low-maintenance branding change.
If no favicon field exists, do not force the asset into an unrelated logo setting. A logo and a favicon have different display requirements, and placing the wrong asset in a branding field can create poor results in both locations.
Method two: add the favicon through the theme or extension
When the configuration interface does not provide the needed control, add the favicon through the storefront’s supported customization structure. The exact files differ between SuiteCommerce implementations, but the outcome is the same: the storefront must render one or more `
` elements inside the document `
`.
A typical implementation looks like this:
<link rel="icon" href="/path/to/favicon.ico" sizes="any">
<link rel="icon" type="image/png" sizes="32x32" href="/path/to/favicon-32.png">
<link rel="apple-touch-icon" sizes="180x180" href="/path/to/apple-touch-icon.png">The paths in this example are placeholders. Use the paths generated by your theme asset process or the URLs provided by the platform after the files are uploaded. Do not copy the example path into production without confirming that the browser can retrieve the file.
For a modern SuiteCommerce implementation, the preferred solution is a small, isolated customization that adds the asset to the theme or uses the supported extensibility model. For SuiteCommerce Advanced, the change generally belongs in the source-controlled theme or extension files that participate in the build process. The precise file depends on the version and how the project manages the document head.
The important principles are consistent:
Store the favicon in the project or asset location that is included in the production build.
Add the `
` markup through a supported template, theme, or extension mechanism.Avoid editing generated bundles or compiled files directly.
Keep the change isolated so future SuiteCommerce updates do not require rediscovering a hidden modification.
Use the existing code review and deployment process, even for a small asset change.
A direct edit to a live generated file might appear faster, but it creates a maintenance problem. The change becomes difficult to track, easy to overwrite, and harder to reproduce in a sandbox or staging environment.
A reliable deployment workflow
Once the asset and markup are ready, deploy them through the same environments used for other SuiteCommerce changes. A favicon should first be tested away from production, especially when the storefront uses a custom theme, custom domain, or multiple shopping experiences.
The deployment sequence should include these core steps:
Add the approved asset to the correct theme or extension location.
Add the favicon references through the supported template or configuration mechanism.
Build or bundle the storefront using the project’s normal commands.
Deploy to the appropriate sandbox or preview environment.
Confirm that the generated asset URL returns the expected file and content type.
Publish to production after functional and visual checks pass.
The build step is easy to overlook. If the project bundles theme assets, adding an image to the local source directory is not enough. The asset must be included in the generated deployment package. Likewise, a template modification that is not part of the active theme will not affect the storefront.
If your business has multiple domains, subsidiaries, or customer-specific storefronts, confirm the favicon behavior for each one. A shared asset may be appropriate, but a branded multi-site setup might require separate icons or separate theme configurations.
Verify the favicon in the browser
Testing should focus on the live rendered storefront, not only on the source code. Open the page in a private browsing window and inspect the document head. Confirm that the favicon links point to the intended URLs and that no obsolete icon references appear ahead of the new ones.
Then check the asset URL directly. It should load without a redirect loop, authentication prompt, permission error, or unexpected HTML response. A browser that receives an HTML error page while expecting an image might display a missing icon even though the file path looks correct in the template.
Test the storefront in the browsers your customers use, including desktop and mobile contexts. Check a homepage, a category page, a product page, and the login or account area if those pages use different rendering paths. A favicon configured only in one template might appear on one route and disappear on another.
Pay particular attention to these verification areas:
Private browsing: This helps separate a deployment issue from a local browser cache.
Multiple browsers: Chrome, Safari, Firefox, and Edge do not always cache or prioritize icons identically.
Mobile shortcuts: Apple touch icons and Android shortcut behavior use different asset conventions.
Responsive routes: Confirm that the icon remains available when the storefront changes layout.
Production domain: A sandbox result does not prove that the published production asset is correct.
Content type: The server should return an image content type that matches the file.
If the old favicon continues to appear, clear the site data for the domain or use a private window. Favicons are particularly persistent because browsers cache them independently from many other page assets. A cache-busting query string is sometimes useful for a controlled implementation, but it should not replace correct asset naming and deployment practices.
Common SuiteCommerce favicon problems
The most frequent issue is not the image itself. It is an incorrect path. A relative URL that works in one route can fail when the browser resolves it from a different path. Asset URLs should follow the structure produced by the SuiteCommerce deployment and theme system rather than depending on the current page URL.
Another common issue is editing the wrong theme. A storefront may contain several themes, extensions, or inherited templates, while only one is active for the published site. Confirm the active theme before changing files.
A stale icon is another recurring problem. Browsers cache favicons aggressively, and a CDN can add another caching layer. Verify the new asset directly, inspect the rendered markup, and test in a private session before concluding that the deployment failed.
Format problems also create confusion. A file named `.ico` that is actually a PNG, an oversized image with an unsuitable color profile, or an SVG that lacks the expected browser support can produce inconsistent results. Use valid files, correct extensions, and explicit MIME types.
Finally, avoid adding many competing favicon declarations. Multiple icons with unclear sizes or priorities make browser selection less predictable. A small, deliberate set of compatible assets produces a more reliable result.
When to involve a SuiteCommerce developer
A favicon update is a small change, but it becomes part of the storefront codebase when configuration support is unavailable. Bring in a developer when the site uses SuiteCommerce Advanced, has a custom build pipeline, includes multiple themes, or relies on a release process that controls all production assets.
Professional review is especially valuable when the favicon change is being made alongside a rebrand, domain migration, mobile experience update, or broader theme redesign. The same implementation should be checked for asset paths, caching, deployment consistency, and accessibility-related brand treatments.
Our NetSuite Developer services are relevant when a team needs help with SuiteCommerce source code, extensions, integrations, or controlled storefront releases. If you want us to review your current setup, contact Versich with the SuiteCommerce version, deployment model, and desired favicon formats.
Conclusion
Adding a custom favicon to a SuiteCommerce site is a focused branding improvement with a simple goal, make the storefront immediately recognizable wherever customers encounter it. The safest approach is to use the platform’s supported configuration when available. When code is required, add the asset through the active theme or extension structure, keep the markup minimal, and deploy it through a controlled workflow.
The final step is verification. Check the generated asset URL, inspect the document head, test multiple browsers and devices, and account for persistent favicon caching. Done correctly, the change remains small, maintainable, and consistent with the rest of your SuiteCommerce implementation.
For broader storefront development, integrations, or help selecting the right implementation path, explore our NetSuite services or contact our team.
