CodeCanyon Nutrition Facts Label Creator - WordPress Plugin

Guide to Setting Up and Using CodeCanyon Nutrition Facts Label Creator

CodeCanyon Nutrition Facts Label Creator should be treated not as a decorative block of numbers, but as a practical tool for recipe pages, food product listings, and nutrition-related content. This guide covers installation, initial checks, working inside WPBakery Page Builder, configuring nutrients, displaying the table on the page, verifying the output, common mistakes, and situations where the plugin is better replaced with a broader recipe solution.

This article does not repeat the product listing. Its main goal is to show how to turn serving size, calories, fats, carbs, protein, vitamins, and minerals into a clear nutrition block on a WordPress site. It also explains where the plugin helps you build a label quickly, and where it does not replace recipe calculation, legal review of nutrition labeling, or a full recipe management system.

The article uses cautious wording and only states facts that could be confirmed from sources. If the tab names or field order in your copy of the plugin are different, rely on the documentation included in the archive, because the developer explicitly identifies it as the main source for installation and setup.

What the Plugin Does and Which Pages It Works Best On

Nutrition Facts Label Creator adds a nutrition facts block to a WordPress site. According to the developer's sources, the plugin is delivered as an add-on for WPBakery Page Builder, adds a dedicated element to the builder, supports a predefined set of nutrients, lets you add custom nutrients, and calculates the daily value percentage based on the entered amount and a standard reference value.

The workflow is straightforward: an editor opens a page or post, adds the Nutrition Facts Label Creator element through WPBakery, enters the serving size and nutrient values, selects a display style, saves the page, and checks the output on the front end. Based on the sources reviewed, the plugin does not calculate recipe nutrition from ingredients; it helps you display values you have already prepared in a clean, structured format.

That is important to understand before installation. If you already have lab data, values calculated in external software, a supplier spreadsheet, or figures provided by a food technologist, the plugin handles the publishing side. If you expect WordPress to calculate nutrition automatically from grams of flour, oil, and sugar, it makes more sense to look at recipe systems with built-in nutrition calculation or use an external calculator before entering the data.

Typical Pages Where the Label Is Actually Useful

The plugin makes sense where the nutrition table should be part of the page itself, not a separate PDF or an image. It is especially useful on sites that already rely on WPBakery and build content from page builder elements.

• A recipe blog post, where the author wants to show calories, fat, protein, carbs, and vitamins next to the ingredients.
• A WooCommerce food product page, if the product description is edited with WPBakery and the customer needs to see serving-based nutrition at a glance.
• A cafe, bakery, or food delivery page, where individual dishes already have verified nutrition values.
• An educational article about foods, diets, or nutrition, where the table helps compare values but should not be presented as medical advice.
• A manufacturer catalog, if each product already has prepared values and the site needs to show them in a consistent format.

The plugin is less useful for a store with hundreds of products where nutrition values need to be imported in bulk from an ERP system, supplier spreadsheets, or a laboratory database. On projects like that, manual entry through a page element quickly becomes a bottleneck. In those cases, it is better to evaluate early whether your team has a process for updating the data and checking changes.

Why the WPBakery Dependency Changes the Implementation Approach

This is not a universal WordPress editor block and not a standalone WooCommerce panel. CodeCanyon Nutrition Facts Label Creator depends on WPBakery Page Builder: the element appears inside the builder environment, not independently anywhere on the site. So before planning implementation, check whether WPBakery is enabled for the relevant post types and whether the editor can open the exact page that needs the label.

From a practical standpoint, this is convenient for sites already built with WPBakery: there is no need to code a template from scratch, and you can simply insert the element next to a recipe or product description. But if the site has moved to the block editor, Elementor, or custom WooCommerce templates, the WPBakery version may no longer be the right fit. The developer offers related versions for Elementor and Gutenberg, but those are separate products, not built-in modes of this plugin.

Who CodeCanyon Nutrition Facts Label Creator Fits Best, and When Another Approach Makes More Sense

A good fit depends less on how attractive the table looks and more on how your data workflow is set up. The plugin solves the problem of displaying a label on a page, not the entire nutrition workflow. So the first step is to determine who will enter the values, who verifies them, and how often they change.

Good-Fit Users

The plugin is especially convenient for a site owner or editor who already works in WPBakery and wants to add a table without separate development. They do not need to hand-code HTML markup, manage classes, calculate percentages manually, or maintain multiple design variants. All they need are prepared values and a clear understanding of which serving the page refers to.

• A food blogger can display nutrition under a recipe if the values have already been calculated.
• A small food producer can add a table to a product page, but should remember that an on-site table does not replace legally required packaging labels.
• An agency webmaster can implement a consistent format across multiple client pages if the site already uses WPBakery.
• A content manager can repeat a simple pattern: open the element, update the values, save, and check the page display.
• A theme developer can refine the appearance through template overrides or careful CSS if the project requires it.

When the Plugin May Not Be the Right Fit

There are several cases where installing the plugin will not solve the core problem. If the site uses only Gutenberg and not WPBakery, it is better to look at the separate Gutenberg version of the product or another block-based solution. If you need automatic nutrition calculation based on ingredients, look for a recipe plugin with a food database or an integration with a nutrition service. If you need printed packaging labels and legal compliance with industry regulations, you need a specialized review process, not just a front-end display block.

Key decision point: if you already have accurate per-serving values and the site is built with WPBakery, the plugin handles the display task well. If you need calculation, imports, printing, or legal label validation, start with another system and use the plugin only as the presentation layer.

How This Product Differs From a Basic HTML Table

Technically, nutrition facts can be displayed in a plain table, but then the editor has to manage rows, percentages, styling, responsiveness, and consistency by hand. The plugin works differently: it turns the values into a ready-made component with multiple styles, predefined nutrients, custom nutrients, %DV calculation, and microdata for recognized nutrition fields. That combination is what makes it practical for repeatable content.

At the same time, a convenient component does not remove the need to verify the data. If the editor enters the wrong serving size or the wrong units, the polished block will simply present incorrect values neatly. That is why your publishing process needs an explicit review step: data source, units, serving size, final percentage, and on-page display.

Source Data Map: What to Prepare Before Opening WPBakery

Nutrition Facts Label Creator works best when the data is already prepared for publication. If an editor opens WPBakery without a ready reference table, they start making decisions directly in the interface: which rows to keep, how to label the serving, what to do with vitamins, where to get the daily value. That increases the chance of accidental errors. Before building the first label, it helps to prepare a simple source data map.

The map does not have to be complicated. For a small bakery, it could be a table in an editorial document. For an online store, it could be a separate sheet in the main product spreadsheet. For an agency, it could be a client brief with columns like "source," "value per serving," "unit," "public label," and "reviewed by." The key is that the editor can see exactly which values are being transferred into the plugin and explain why that specific serving is shown on the page.

Minimum Set for a Recipe

A recipe usually has a natural serving unit: one bowl, one slice, one serving of salad, one muffin. In recipe content, the user is usually looking for a practical reference point, not manufacturing labeling. So it is enough to start with the rows that actually shape how the dish is understood: calories, fat, carbs, protein, sugar, fiber, sodium, and a few vitamins or minerals if they are meaningful.

If the recipe changes serving counts through another plugin, be careful. Based on confirmed sources, Nutrition Facts Label Creator displays entered values and calculates %DV, but it is not confirmed that it syncs with dynamic serving changes in another recipe plugin. In that case, it is safer to show fixed nutrition facts "per serving" and avoid promising automatic recalculation when ingredient quantities change.

Minimum Set for a Food Product

For a product page, the bar is higher because the customer treats the page as information about a specific product. Prepare the product name, serving size, servings per container, calories, fat, saturated fat, trans fat, cholesterol, sodium, carbs, fiber, sugars, protein, and any vitamins or minerals that appear in verified documentation. If the source documentation includes allergen information, it is usually better to show that in a separate WooCommerce text block rather than mixing it into the nutrition table, unless the plugin is specifically built for allergens.

Do not replace unknown values with zeros. A zero in a table is read as a factual claim, not "data unavailable." If a metric was not measured or calculated, it is better to hide that row if the interface allows it. If the project requires the row to remain visible, create an internal task to verify the data instead of publishing an approximate value.

Verification Table Before Entry

Below is an example of an editorial reference table. It is not part of the plugin, but it helps you move data into WPBakery safely and later trace the source of a disputed value.

Example of a data map before creating a nutrition label

Check Field	What to Record	Why It Matters
Serving size	For example, 1 muffin (80 g) or the public-facing wording used on the page	All nutrients need to refer to that same serving.
Data source	Lab, food technologist, supplier, external nutrition calculator	The team knows where the values came from and who is responsible for checking them.
Unit	g, mg, mcg, or another unit from the source document	Unit errors directly break %DV.
Reference value	For custom nutrients, only a confirmed reference value	Without a correct baseline, the daily value percentage will be misleading.
Public label	How the name will appear on the site	The wording should be clear and fit within the selected style.

A table like this is especially useful when you have many pages. It separates nutrition data from visual formatting. The editor does not negotiate with the interface; they simply transfer prepared values into the element. After a product update or recipe change, you can quickly reopen the source map and identify which pages need revision.

The Single-Basis Rule

The most common logic error is mixing different bases. One part of the page says "per 100 g," the label shows "1 serving," and the values were copied from a per-package calculation. Visually, the table may look flawless, but the user gets the wrong reference point. That is why you need a single-basis rule: every row in the label should answer the question "how much of this nutrient is in the stated serving".

If you need to show both "per serving" and "per package," check whether your version of the product supports that format. If it does not, do not try to mimic a complex two-column label by inventing custom rows without testing. It is better to create one clear block and explain separately how many servings are in the package.

What to Check Before Installing It on WordPress

Preparation before installation saves more time than troubleshooting afterward. Nutrition Facts Label Creator is one of those plugins where the main issue often comes not from the code itself, but from an unsuitable environment: WPBakery is not installed, the builder is not enabled for the needed post type, the theme overrides styles too aggressively, or the editor is entering data in the wrong unit system.

Platform, Builder, and Post Types

First, confirm that the site actually uses WPBakery Page Builder and that the relevant pages can be opened in that builder. The CodeCanyon listing explicitly states that the plugin is an add-on for WPBakery and requires the builder to be installed separately. If the target WooCommerce product page or custom post type is not edited through WPBakery, the element may not appear where you expect it.

For a WooCommerce site, check where exactly you plan to display the label. Traditional product pages usually have a long description, a short description, and tabs. If WPBakery is used in the long description, the label is easy to place there. If the product page is assembled through a theme template, a product builder, or the block editor, the implementation path may be different.

Nutrition Data and Responsibility for Accuracy

Before installation, prepare the source value table. A minimum working set includes serving size, calories, fat, saturated fat, cholesterol, sodium, carbs, fiber, sugar, protein, and any key vitamins or minerals relevant to your page. For a food product, it is best to keep the data source alongside it: a lab report, a food technologist's calculation, a supplier document, or an internal spreadsheet.

The on-site table should match what you are promising the user. If the product is sold physically and falls under nutrition labeling requirements, do not treat the appearance of the block as proof of compliance. FDA guidance and other regulators define rules for nutrients, serving sizes, and daily values, while the plugin only helps display part of that information on the website.

Theme, Cache, and Styling

The plugin claims responsive output and a layout built without HTML tables, but any theme can still interfere with lists, fonts, line spacing, and block widths. This is especially noticeable on recipe pages that also contain cards, columns, tabs, accordions, or WooCommerce blocks. Before publishing at scale, create a test page and check it on both desktop and mobile.

Caching plugins usually do not break a static nutrition block, but they can continue showing an old version of the page after the data changes. So after editing values, clear the page cache, the builder cache if it exists, and the CDN cache. Check the page in incognito mode so you do not mistake an admin preview for the real visitor-facing output.

Language and Text Direction

The developer states that the plugin is translation-ready and supports RTL layouts. In practice, that means you should manage localization through WordPress's standard translation system rather than editing plugin files directly. If the site is multilingual, decide in advance whether the values and labels will be identical across languages or whether each language version will have its own element with its own text.

Installation and the First WPBakery Element Check

Installing a commercial WordPress plugin is usually done by uploading a ZIP archive through the admin panel. WordPress supports ZIP plugin uploads through Plugins - Add New - Upload Plugin. The Nutrition Facts Label Creator developer also notes that detailed documentation is located in documentation/index.html inside the main download archive.

Do not confuse the purchase archive with the installable plugin archive. Commercial products often include documentation, a license, examples, and a separate install ZIP inside the main ZIP. If WordPress says the archive does not contain a valid plugin, the wrong file was probably uploaded. The safe approach is to extract the main archive locally and locate the actual install ZIP for the plugin without changing the folder contents.

Basic Installation Sequence

1. Open the WordPress admin panel and make sure WPBakery Page Builder is already installed and activated.
2. Go to Plugins - Add New - Upload Plugin.
3. Select the Nutrition Facts Label Creator install ZIP, not the full archive that includes documentation.
4. Click Install Now and then choose Activate Plugin after installation.
5. Open a page or post where WPBakery is already enabled and confirm that the new element appears in the builder element list.

After activation, do not start by editing a live product page. Create a draft or a private test page first. That lets you check styles, fields, and element behavior without risking unfinished data appearing to visitors.

First Test Block

For the first test, you do not need to enter the full nutrient set. A small validation label is enough: product name, serving size, calories, fat, carbs, protein, and one vitamin or mineral. The purpose of this test is not nutrition accuracy, but confirming that the element opens, saves values, displays rows, and renders correctly on the front end.

Quick post-install check: open the page as a regular visitor and make sure the block is visible, does not stretch the column, keeps its bold divider lines, does not break the mobile layout, and does not disappear after cache is cleared.

If the Element Does Not Appear

Start with the basics: make sure you are editing the page through WPBakery itself. Then check whether WPBakery is active for that post type. The official WPBakery documentation includes settings and mechanisms for post types and third-party elements, so the issue is often related not to Nutrition Facts Label Creator, but to builder configuration or user role restrictions.

If the element is visible to an administrator but not to an editor, check access permissions inside WPBakery and the user's WordPress role. If the element appears on a regular page but not in a WooCommerce product, check whether the builder is enabled for products and whether another template is replacing the product page layout.

Configuring the Nutrition Label: From Serving Size to Custom Nutrients

The most important part of the job is not choosing an attractive style, but structuring the data correctly. Nutrition Facts Label Creator takes the values you enter, matches them to standard reference values, and displays the daily value percentage. If the user enters the wrong unit, the wrong serving size, or mixes per-100-gram values with per-serving values, the final output may look polished while the meaning is wrong.

General Data and Serving Size

Start with what the user sees at the top of the label: the name, serving size, servings count, or other context if your version of the element includes it. For a recipe, that might be "1 serving" or "1 slice"; for a product, "30 g," "1 package," or "100 ml." The important part is that every value below it must refer to that same basis.

If your source values are given per 100 g, but the page says "per 35 g serving," you need to recalculate before entering anything. The plugin calculates daily value percentages from the entered amount and the reference value, but it has no way to know that your source was based on a different weight. The base unit must be verified before saving the element.

A Safe Data Entry Order

1. Record the data source and serving size in a separate table or document.
2. Convert all values to the single serving that will be shown in the block.
3. Enter calories and the main macronutrients.
4. Add vitamins, minerals, and extra rows only when they are truly confirmed.
5. Save the element and compare the front-end output with the source table.

Predefined Nutrients

According to the product listing, the WPBakery version includes 39 predefined nutrition components with standard values. That is useful for common rows because the plugin can automatically calculate %DV for recognized nutrients and use Schema.org microdata where supported. Only enter rows you actually have data for; empty or meaningless zero values can reduce trust in the page.

For the reader, not every available field matters equally. What matters are the values that help explain the product. In a high-fiber recipe, it makes sense to show fiber and carbs. In a salty snack, sodium is important. In a dairy product, calcium and protein are often key. The plugin provides the interface, but the editor still has to decide which rows help the user and which ones just add noise.

Custom Nutrients and Nested Rows

One confirmed feature of the product is the ability to add an unlimited number of custom nutrients through drag and drop, specify the name, standard reference value, unit, and daily value, and create nesting up to three levels deep. That is useful when the standard list is not enough or when you need to show a clarifying row under a broader value.

For example, under "Fat" you could add "Omega-3" if you have verified data for it and it matters for the product. Under "Carbohydrates" you could add sugar alcohols or another relevant sub-value if that is actually used in your niche. But do not add custom rows just for completeness. Every additional row increases your responsibility for the source and the units.

How to Avoid Mistakes With a Custom Row

• The row name should be clear to the visitor and match the source document.
• The unit must be consistent for that entire row: grams, milligrams, and micrograms should not be mixed.
• Only enter a standard reference value if you understand where it comes from and why the percentage matters.
• Use nesting for meaningful hierarchy, not just to create visual indentation.
• After saving, check that the row does not become too long on a mobile screen.

Rounding and Questionable Percentages

The WPBakery version confirmed by the product listing supports automatic %DV calculation, but it does not show a separate rounding control for that version. Related Elementor and Gutenberg versions mention a percentage rounding option in their changelogs, so this article cannot confidently claim that the WPBakery version has it unless you can see it in your own documentation or interface. If your version includes rounding, use it for readability, not as a way to hide inaccuracies in the underlying data.

The practical rule is simple: the daily value percentage is useful for giving a quick sense of nutrient proportion, but it depends on both the reference value and the serving size. If the percentage looks unexpectedly high or low, check not only the formula, but also the original unit, the serving weight, and the reference value in the settings.

How Entered Values Become a Visible Table and Structured Data

The product has a useful, non-obvious chain worth understanding before publishing labels at scale. The editor is not just entering text rows. They are passing a data set into the element: serving size, nutrients, values, units, standard reference values, nesting, and style. The plugin then generates HTML output, calculates percentages, and for recognized nutrients adds Schema.org microdata if that feature is active and applicable.

Input: Per-Serving Data

The plugin's input is the set of values you enter into the WPBakery element. Units matter most at this stage. Calories are usually entered as an energy value, sodium and cholesterol in milligrams, many macronutrients in grams, and vitamins or minerals in either micrograms or milligrams. If the source uses a different form, convert it in advance.

The plugin cannot infer whether "12" means 12 grams, 12 milligrams, or 12 percent if the field expects a specific unit and the editor enters a bare number without understanding the context. That is why the editorial process needs a separate units check. It is not glamorous, but it is critical.

Processing: %DV Calculation and Row Order

When a row has both an entered value and a standard reference value, the plugin calculates the daily value percentage. In simplified terms, the product value is divided by the reference value and converted into a percentage. For custom nutrients, this depends on whether you entered a correct reference value. For nutrients without a widely accepted percentage basis, the value may appear without %DV or may require careful setup.

Row order and nesting affect readability almost as much as the numbers do. Users expect major groups to appear higher up and clarifying lines to sit below them. If you place a niche vitamin before calories or bury sodium deep near the end, the block may be technically complete, but it becomes harder for the reader to compare the product quickly.

Output: HTML Without Tables and Theme Behavior

The developer states that the output is built without HTML tables and uses lists while still keeping valid HTML markup. That can be an advantage for responsiveness: lists are easier to adapt on narrow screens than rigid tables. But it also means that theme styles for lists may affect the appearance. If the theme adds bullets, spacing, or custom styling to all lists, the label may look different from the demo.

Structured Data: What It Helps With and What It Does Not Guarantee

Schema.org defines the NutritionInformation type and properties such as calories, fatContent, carbohydrateContent, proteinContent, sodiumContent, and servingSize. The plugin listing confirms schema microdata support for recognized nutrients. That can help search engines understand part of the data better, but it does not guarantee rich results and it does not fix incorrect values.

If the page is a recipe, check the site's overall recipe schema structure. NutritionInformation is useful as part of a recipe entity, but by itself it does not turn an arbitrary page into a complete recipe eligible for recipe search features. If recipe SEO is a core goal, compare this plugin with full recipe plugins that manage ingredients, steps, cook times, ratings, and JSON-LD.

Six Label Styles and How to Work With the Design

The developer advertises six label styles, including an FDA-style option. The point of choosing a style is not to find the flashiest design, but to make sure the block is clear for your audience. For a food product, users often expect a strict, familiar table. For a recipe blog, a softer style can work if it remains readable and does not hide important values.

How to Choose a Style for Different Pages

On a product page, it usually makes sense to start with a strict look that feels close to familiar nutrition labeling. It is faster for shoppers to scan and less likely to look like a promotional insert. On a recipe blog, you can choose a lighter style if the page already includes a recipe card, photos, and step-by-step blocks. On an educational page, a compact version may work better if you do not want the table to distract from the explanation.

Test each style with real data. Demo values are often short and tidy, while real labels may include longer lines such as "Monounsaturated Fatty Acids," "Dietary Fiber," "Vitamin B6," or "Potassium." If a style only looks good with short labels, it may become awkward once longer wording is used.

Color, Width, and Typography

The design should serve two goals: readability and trust. Overly bright colors make the block look like a banner, while weak contrast hurts accessibility. Type that is too small turns the table into a decorative detail. For a typical site, the safest choice is a neutral base, solid contrast, and one accent color if the selected style supports it.

If the element includes color settings, change them gradually: first pick the style, then check width, then fonts, and only after that adjust accents. That makes it easier to identify which setting is causing a problem. If you change everything at once, troubleshooting becomes harder.

Careful CSS Refinement Without Editing the Plugin

If you only need to improve spacing or block width slightly so it fits the theme, it is safer to add CSS in a child theme or in WordPress's built-in custom styles area. Do not edit the plugin files directly: updates will overwrite your changes. Below is a cautious example. The selector is intentionally generic and should be refined after inspecting the actual markup generated by your version in browser dev tools.

/* Add this to a child theme or to "Additional CSS."
   Before publishing, refine the container class based on the real block markup. */
.nutrition-facts-label,
.nflc-label {
  max-width: 420px;
  margin: 24px 0;
  line-height: 1.25;
}

.nutrition-facts-label li,
.nflc-label li {
  list-style: none;
}

The check is simple: after adding the CSS, open the page on desktop and mobile and make sure the lists do not show extra bullets, the block is not wider than its column, and the values do not collide with the labels. If the display gets worse, remove the snippet or refine the selector. This is an author-created adaptation based on standard WordPress practice and the confirmed fact that the plugin output is built with lists rather than an official developer-provided snippet.

Template Override in the Theme

The product listing confirms that the nutrition table template can be overridden in the theme. That is a powerful option for a developer, but it requires care. A template override makes sense when CSS is no longer enough, for example when you need to change the order of specific containers, add a wrapper that matches the theme design, or integrate the block into a custom layout grid.

Before overriding anything, find the exact path and rules in the plugin documentation from the archive. Do not copy the template blindly. After moving the template into the theme, note which plugin version you used and review the file after plugin updates. If the developer changes the template structure, an old override may hide new fixes.

Practical Ways to Use It on a Site

The same element can solve different problems. On a recipe page, it helps the reader evaluate the dish. On a product page, it reduces questions before purchase. In an educational article, it makes product comparisons easier to understand. In each use case, not only the placement changes, but also the row selection, style, review process, and risk of error.

Recipe With a Fixed Serving

For a recipe, it is usually best to place the label after the ingredient block or after a short description of the finished dish, but before long comments and promotional inserts. That way, the user first understands what they are making and then sees the nutrition facts. If the table is too low on the page, it loses practical value. If it appears before the recipe, it can feel like dry technical information with no context.

Only enter confirmed values. If the recipe is homemade and the numbers were calculated in an external tool, you can carefully note near the recipe that the values are approximate, if that aligns with the site's editorial policy. But do not cram long disclaimers into the label itself unless the plugin is designed for that.

Product With Multiple Flavors or Variants

If a WooCommerce product has variants, such as different bar flavors, the nutritional composition may differ. The simplest approach is a separate label in each product description or separate pages for each variant. If all variants live on one product page, think about whether stacking multiple tables will overload the page. In some cases, it is better to create a short comparison block outside the plugin and use Nutrition Facts Label Creator only for the main variant.

Do not claim automatic integration with WooCommerce variations unless you have confirmed it in your version's documentation. The confirmed use case is adding the element to a product description where WPBakery is enabled. Anything involving dynamic label changes when a variation is selected requires separate validation or custom development.

Reference Article About a Product or Ingredient

In educational content, the label should help explain differences, not sell the item. For example, you could show the per-serving nutrition facts for nut butter and then explain in the surrounding text why sodium, sugar, or fiber matter for comparison. In that setup, the table should stay compact and sit next to an editorial explanation. Without that explanation, the user sees numbers but does not know how to interpret them.

Cafe and Food Delivery Pages

For a cafe menu, the label can be useful on individual dish pages. But if you have dozens of items, manual entry in WPBakery requires discipline. Create an internal template: where the label appears, which rows are required, who approves the data, and who updates the page when the recipe changes. If dishes change frequently, it may make more sense to use a system that stores nutrition data as structured fields rather than inside a visual page element.

Editorial Workflow for Multiple Authors

If several people create labels, agree on a consistent process. One author might write "80 g," another "80g," and a third "1 muffin." Visually, that seems minor, but on a large site, inconsistency reduces trust. Create a short style guide: how to write serving sizes, which names to use, when to add custom nutrients, how to verify percentages, and what to do after a plugin update.

One of CodeCanyon Nutrition Facts Label Creator's strengths is that it gives you a repeatable element in a familiar WPBakery environment. For that strength to matter, the team process also needs to be repeatable. If every editor uses the element differently, the plugin turns into a collection of disconnected tables.

Practical Example: A Nutrition Table for a WooCommerce Product

The developer explicitly cites the WooCommerce product description as one place where the element can be used, provided WPBakery is enabled for that post type. Here is a practical example: a bakery has a product called "Banana Muffin," the per-serving values are already prepared, and the goal is to display nutrition facts in the product's long description.

Goal

The goal is for the customer to see nutrition information next to the product description: serving size, calories, fat, carbs, sugar, protein, sodium, and a few verified nutrients. The block should display consistently on desktop and mobile, should not break the product tabs, and should not conflict with the theme.

Preparation

Before opening WordPress, prepare a per-serving value table. In this example, it could be one muffin weighing 80 g. The data source should be clear to the team: a food technologist's calculation, a lab, or an approved spreadsheet. Also confirm that the product already exists in WooCommerce and that its long description is editable through WPBakery.

Setup Steps

1. Open the product in the admin panel and switch to editing the long description in WPBakery.
2. Add the Nutrition Facts Label Creator element where the table should appear, such as after the ingredient description or before a questions block.
3. In the general settings, enter the product name and serving size, for example "1 muffin (80 g)."
4. In the nutrients section, fill in the main values: calories, fat, saturated fat, carbs, sugar, protein, and sodium.
5. Add extra rows only for nutrients that are confirmed in the source table.
6. Choose a strict style if the product is sold as a physical item, and a softer style if this is an informational recipe page.
7. Save the element, update the product, and clear the page cache.

Verifying the Output

Open the product page as a regular visitor. Compare each row to the source table. Make sure the serving size is written the same way in both the description and the label. Then open the page on a phone: the values should stay readable, the rows should not spill outside the column, and the WooCommerce purchase block should not overlap with the table.

Quick takeaway: this workflow is not complete until you have checked the source values, the public-facing display, the mobile version, and the cache. Simply saving the element in the admin panel does not prove that the customer will see the correct table.

A WooCommerce Tab Detail to Watch For

If the theme places the long product description inside a tab, the nutrition table will also appear inside that tab. That is fine if visitors are used to reading the description there. But if the nutrition facts need to appear higher up, near the price or purchase button, you may need WooCommerce template customization or a dedicated product page builder. Do not move the block into a nonstandard location without checking it on mobile and understanding how the theme assembles the product page.

Verifying the Output: Data, Markup, Mobile View, and Cache

Verification should be a dedicated publication step, not a quick glance at the page. Nutrition Facts Label Creator works with numeric data, and an error in a single row can still look like polished information. That is why you need to verify four layers: data accuracy, visual display, technical markup, and post-cache behavior.

Data Cross-Check

Create a control table: source row, value in the element, value on the public page. For the core nutrients, verify not only the number but also the unit. If the source lists sodium in grams but the site expects milligrams, the error will be significant. If vitamin D is listed in micrograms and the editor mixes up the unit, the percentage will become unreliable.

Pay especially close attention to rows where the product changelog already reflects changes to standard values or units. For example, the developer has documented updates to vitamin and mineral reference values and a shift from IU to metric units in older versions. That does not automatically mean your site is wrong, but it shows why updates and rechecks matter.

Structured Data Check

If recipe SEO matters to the project, do not stop at the visual block. Check the page with a structured data tool and make sure the nutrition information appears in a clear page context. Schema.org supports NutritionInformation properties, but search visibility depends on the entire page, not just the individual block.

If the page already uses another recipe plugin, verify carefully that there are no duplicates or contradictions. Two different systems may output different calorie or protein values. For users, that looks like the site is unreliable; for search engines, it creates ambiguous data.

What to Look For in Structured Data Validation

Do not just check whether the word NutritionInformation appears. Look at which properties are populated, whether calories, fatContent, or proteinContent are duplicated, and whether the nutrition data sits in a logical recipe or product context. If the tool reports a warning, do not rush to change the label itself. First determine which plugin or template is generating the main page schema.

If the page already has a full recipe plugin and Nutrition Facts Label Creator is added only as a visual block, there are two possible approaches. One is to use a single nutrition source and disable the duplicate in the second tool if that is possible. The other is to keep the visual block but make sure the page's structured data does not contradict it. The right choice depends on the theme, the SEO plugin, and the editorial workflow.

Mobile Display and Accessibility

On a narrow screen, long labels may wrap onto two lines. That is fine as long as the values remain clearly associated with the correct rows and nothing overlaps. Check contrast, font size, and spacing. If the table is too small, users will not zoom the page just to read each nutrient.

Also make sure the block is not being turned into an image. The advantage of HTML output is that the text remains accessible, indexable, and adaptable to the screen. If the theme or a third-party optimization layer converts part of the content into an image or breaks the list structure, it is better to disable that optimization for this page.

How to Check Long Labels

Open the label with real production labels, not only short demo words. Lines such as "Saturated Fat," "Dietary Fiber," "Added Sugars," and "Monounsaturated Fatty Acids" behave differently from "Fat" or "Sugar." If the column is narrow, the label may wrap to two lines while the value drops below it. That is not always an error, but the user should still be able to tell easily which number belongs to which row.

If the problem appears only in one theme, first try a different label style or a wider column. If it happens in every style, address it with targeted CSS and document that as part of the project. It is not worth replacing clear labels with cryptic abbreviations just to fit one column: it is usually better to widen the block or choose a style with more forgiving typography.

Cache and Republishing

After changing values, clear the page cache and CDN cache if one is in use. Then open the page while logged out of the admin panel. If you still see old values, check WooCommerce cache, builder cache, and HTML optimization. Do not conclude that the plugin "is not saving" until cache has been ruled out.

Editorial Review Before Publishing

Before publishing each label, run through a short checklist. It is not bureaucracy; it protects you from mistakes that are hard to catch once the page is indexed.

• The serving size matches the recipe text, the product page, and the source table.
• The units are consistent, and the values do not mix grams, milligrams, and micrograms.
• The percentages look reasonable and do not contradict a quick manual spot check.
• Custom nutrients have a source, rather than being added just to make the table look more complete.
• The mobile view is readable without horizontal scrolling or overlapping rows.
• The cache has been cleared, and the page has been checked as a regular visitor would see it.

If the team manages a large catalog, this checklist can be attached to the publication task itself. The plugin simplifies output, but the quality of the final result still depends on editorial control.

SEO, Trust, and the Limits of a Nutrition Label

A nutrition label can make a page more useful, but it should not be treated as a guaranteed ranking boost. Search engines care about accuracy, structure, completeness, and alignment with user intent. Nutrition Facts Label Creator helps present part of the data and, according to the developer, supports structured data for recognized nutrients. But it does not replace a strong recipe, a solid product description, photos, reviews, customer questions, or technical site optimization.

When the Label Strengthens the Page

The label helps when it answers a real visitor question. A food product customer wants to understand calories, sugar, sodium, or protein quickly. A recipe reader wants to evaluate the serving. A visitor reading an educational article wants to compare products. In those cases, the table makes the page more reference-oriented instead of purely promotional.

A strong page usually combines multiple layers: a clear product description, ingredients, storage or preparation details, nutrition facts, allergen warnings, FAQ, and verifiable data. The plugin only handles one of those layers, but it can still be an important one when used carefully.

When the Label Can Hurt Trust

The problem appears when the block looks authoritative but the data has not been verified. Users see a strict format and assume the numbers are precise. If the values are approximate, generated without review, or tied to the wrong serving, the site risks losing credibility. That is why the publication process needs a corresponding source-check step behind the scenes.

Do not say in the article or product page that the table guarantees compliance. Even if you choose a style that resembles familiar labeling, legal responsibility depends on the country, product category, packaging, composition, and labeling rules. For a commercial product, consult a food labeling specialist.

Using It Alongside Other Site Features

The plugin can be used sensibly with standard WordPress and WooCommerce features. For example, the label itself can sit in the long product description, while the short description highlights the product's main benefit. The "Additional Information" tab can store weight and attributes, and Nutrition Facts Label Creator can display the nutrition values. This is not an officially documented developer integration, but it follows normal WooCommerce and WPBakery usage.

One possible issue is duplicated information. If the product weight appears in WooCommerce attributes, the short description, and inside the label, make sure those values stay consistent. If the recipe changes, update every location. It is useful for the team to keep an internal list of pages where the nutrition label is used.

How to Write the Surrounding Text So the Label Does Not Feel Detached

The label works better when it has context around it. For a recipe, that might be a short line such as "Nutrition facts are calculated per serving." For a product, "Values are listed for one serving from the package." For an educational article, "Compare products only at the same serving size." That surrounding text should not conflict with the table; it should explain the basis of the data.

Do not overload the label with marketing language. Claims like "healthy," "diet-friendly," or "light" are better handled separately and cautiously. Inside the table, what users should see are values, units, and clear nutrient names. That keeps the line between factual data and editorial interpretation clear.

Impact on Page Speed

The product listing claims clean, optimized code, responsive output, and a layout built without tables. Even so, page speed still deserves verification, especially if the page is already heavy with builder elements, galleries, reviews, and third-party scripts. The nutrition block itself usually should not be the main source of load, but WPBakery pages often become heavy because of the overall number of elements.

A practical check is simple: compare the page before and after adding the label, see whether any unexpected styles or scripts were introduced, and review the mobile display. If the difference is noticeable, evaluate not just Nutrition Facts Label Creator, but the page structure as a whole. Sometimes the fix is as simple as moving the block into a cleaner WPBakery row or disabling unnecessary theme animations.

Trust and Legal Caveats

For food products in particular, it is important to separate the website's informational block from the official package label. FDA guidance explains that serving size, calories, %DV, and the nutrient list follow specific rules for interpretation and use. An on-site table can help the customer, but it should not promise more than your verification process can support.

If the product is sold in multiple countries, regulations may differ. In that case, do not create one universal label "for all markets" without expert review. You can still use Nutrition Facts Label Creator on the site as a convenient way to display values, but compliance for packaging and page copy should be reviewed separately.

Why the Label Is Not Showing or Displays Incorrect Values

Troubleshooting is best done from the environment outward to the data. First make sure WPBakery and the element itself are working, then check saving behavior, then appearance and cache, and only after that move on to more complex theme conflicts. That way, you do not waste time on CSS if the real problem is that the element was never added to the correct post type.

The Element Is Not Visible in WPBakery

Symptom: the user opens the WPBakery element list but cannot find Nutrition Facts Label Creator. Possible causes include the plugin not being activated, WPBakery not being active, the builder being disabled for the current post type, or the user's role being restricted.

What to check: the list of active plugins, whether WPBakery is installed, whether the page is being edited through WPBakery, and the builder's role and post type settings. If the element appears on a page but not in a WooCommerce product, check whether the builder is enabled for products.

How to fix it: activate the required plugins, enable WPBakery for the correct post type, and verify editor permissions. If the element still does not appear after that, open the archive documentation and the product support comments, because the element name or category in the list may differ.

The Values Were Saved, but the Old Version Still Appears on the Page

Symptom: the new numbers are visible in the admin panel, but visitors still see the old table. Most often, this is caused by page cache, CDN cache, or builder cache. The plugin outputs a static HTML block, so cache can keep serving an outdated fragment for a long time.

What to check: open the page in incognito mode, clear the cache for that specific page, and temporarily disable HTML optimization during testing. Compare the result for an administrator versus a regular visitor.

How to fix it: clear cache at every layer and make sure the page is not excluded from refresh rules. If the values change often, add a required cache-clearing step to the publication process whenever nutrition data is updated.

The Daily Value Percentages Look Wrong

Symptom: the percentage is too high, too low, or does not match a manual calculation. Common causes are the wrong unit, values entered per 100 g instead of per serving, an incorrect standard reference value for a custom nutrient, or outdated data in an older plugin version.

What to check: the serving size, units, source document, reference value, and plugin version. For custom nutrients, also make sure the standard value is entered in the same unit as the product value.

How to fix it: recalculate everything to a single serving, correct the unit, update the reference value, or temporarily remove the percentage from the disputed row if your version allows it. If the metric matters for a commercial food product, do not publish it without specialist review.

The Rows Break on Mobile

Symptom: row labels wrap unpredictably, values spill outside the column, or list bullets appear. A likely cause is that the theme applies global list styling or that the block is placed inside a column that is too narrow in WPBakery.

What to check: column width, theme list styles, the selected label style, and any extra CSS adjustments. Open browser dev tools and identify which rules are controlling spacing and markers.

How to fix it: choose a more compact style, move the block into a wider column, or add targeted CSS in the child theme. If the issue appeared after a theme update, temporarily disable your own custom fix and compare it with the original plugin styling.

The Structured Data Does Not Produce the Expected SEO Outcome

Symptom: the nutrition data is visible on the page, but search results do not show the rich elements you expected. The reason may be that NutritionInformation is not embedded in a complete recipe structure, the page contains conflicting schema, or the search engine simply chose not to display an enhanced result.

What to check: a structured data testing tool, the presence of other recipe plugins, duplicate values, and the overall page type. Do not look for the problem only in Nutrition Facts Label Creator if the page's full recipe entity is incomplete.

How to fix it: remove contradictions, choose one primary source of recipe schema, and use the plugin as a visual block if a different tool is already responsible for the full SEO schema.

Limitations, Updates, and Safe Long-Term Maintenance

The product has several limitations that should be accepted before implementation. It depends on WPBakery, is not a standalone recipe calculation system, requires accurate source data, and may need review after updates. Those limitations do not make it weak. They simply help define its proper role in the project.

Watch the Changelog

The changelog for the WPBakery version shows that the developer has updated nutrition reference values, checked compatibility with newer versions of WordPress, WPBakery, and PHP, fixed a PHP warning, replaced IU units with micrograms and milligrams, removed the "calories from fat" line, and updated the default style to reflect newer labeling requirements. That is an important signal: nutrition data and label formatting are not frozen forever.

After updating the plugin, check several published pages. Compare the old and new appearance, percentages, units, and rows. This matters especially for sites where the tables appear on commercial pages. Updates should go through a staging copy of the site if nutrition labels are business-critical.

Do Not Edit the Plugin Core

Even if you only need to change a label or a bit of spacing quickly, do not edit the plugin files directly. Use the element settings, translation files, a child theme, custom CSS, or a documented template override. Direct file edits are almost always lost in updates and make maintenance harder.

Working With Daily Value Filters

The product listing confirms support for filters that can modify standard daily values for nutrients, but the public product page does not reveal the exact filter names. That means this guide cannot safely provide a ready-made PHP snippet without risking a fabricated API. If you need that level of customization, find the exact filter names in the archive documentation or in your version's source code and implement them through a child theme or Code Snippets on a staging site.

Without a confirmed filter name, it is safer to change the reference value for a custom nutrient through the element interface if the adjustment is local, or to contact the developer. That is slower, but more reliable than adding a random hook.

Localizing Labels

The developer states that a POT file is included. For an English or another localized version, use the standard WordPress localization workflow: create PO/MO translations with the appropriate tool or translation system without editing the original files. After translation, check long labels on mobile. Short English labels often take less space, while other languages may need a little more width or a different style.

Questions About Setup, Limits, and Real-World Use

Can the plugin be used without WPBakery Page Builder?

For the WPBakery version discussed here, the sources confirm that WPBakery is required. If the site does not use that builder, the element will not fit naturally into the editing workflow. The author offers separate Elementor and Gutenberg versions, but those are different products and need to be chosen separately based on the site's stack.

Does the plugin calculate recipe nutrition from ingredients on its own?

Based on the sources reviewed, the WPBakery version is designed for entering and displaying nutrition values, as well as calculating daily value percentages from entered amounts and standard reference values. Automatic ingredient-based calculation is not confirmed for this version. For that use case, recipe plugins or external nutrition services are a better fit.

Can the label be used in WooCommerce?

Yes, if WPBakery is enabled for the product description or whichever part of the product page you want to use for the element. The developer explicitly mentions the WooCommerce product description as an example. But the exact placement on the page depends on the theme, product templates, and where WPBakery is actually used.

Why is %DV different from my manual calculation?

Check the serving size, the units, and the standard reference value. A common cause is that the source data is calculated per 100 g while the site shows a single serving at a different weight. For custom nutrients, it is also important that the product value and the standard value use the same unit.

Is the plugin suitable for official packaging nutrition labeling?

The plugin helps display a nutrition table on a website. It does not replace legal labeling review, laboratory data, or the requirements of the country where the product is sold. Commercial packaging needs separate review by a specialist or an industry-specific service.

Can the labels be translated?

The product listing confirms translation readiness and the inclusion of a POT file. Use the standard WordPress localization workflow instead of editing plugin files. After translating, check the mobile layout, because some languages may require longer labels than English.

What should I do if the theme breaks the table layout?

First try a different label style and a different WPBakery column width. Then identify the conflicting theme CSS rules. Fix it through a child theme, additional styles, or a documented template override, but do not edit the plugin files directly.

Do I need to add every available nutrient?

No. Only add rows that are confirmed and useful. A large table without a reliable data source reduces trust and makes verification harder. For custom nutrients, always document the source, unit, and reference value if you are displaying a daily value percentage.

When CodeCanyon Nutrition Facts Label Creator Is Worth Using

CodeCanyon Nutrition Facts Label Creator is a good choice for a WordPress site that already uses WPBakery Page Builder and needs a clean nutrition label on recipe pages, product pages, or educational content. Its strengths include a ready-made builder element, multiple styles, predefined nutrients, custom rows, %DV calculation, RTL and translation support, template override capability, and structured data for recognized nutrients.

The plugin should not be viewed as a nutrition calculation engine or a legal labeling tool. It requires prepared data and careful review. If that matches your workflow, you can test it on a staging copy of the site and then get the CodeCanyon Nutrition Facts Label Creator file, install it on a test page, build one label, and verify the entire path from the source table to the public-facing output.

The best implementation order is this: first confirm that WPBakery fits the target pages, then prepare the data source, create a test block, verify the percentages and the mobile layout, adjust the style, clear the cache, and only after that move the label onto live recipes or products. That approach takes a little more time upfront, but it protects you from the most common failure mode: a beautiful table built on unverified values.