What does "In an Array literal, a row was the wrong size" mean in Google Sheets?

This is the exact tooltip for the `array_literal` error (`#ERROR!`). It means your curly-brace array contains rows with different numbers of columns, making the grid non-rectangular. For example, row 1 might have 4 elements and row 2 might have 3. Google Sheets can't build a rectangular array from that, so it fails at parse time before evaluating anything. The tooltip distinguishes this specific cause from other `#ERROR!` cases like mismatched parentheses.

Can IFERROR suppress the array_literal error?

No. `IFERROR` only catches runtime errors like `#N/A`, `#VALUE!`, and `#REF!`. The `array_literal` error is a parse-time failure - it happens before the formula runs at all. `IFERROR` wrapping does nothing. The only fix is correcting the dimensional mismatch itself. If you want a formula that tolerates unequal array dimensions, switch to `VSTACK` or `HSTACK`, which pad mismatched rows with `#N/A` rather than erroring.

When should I use VSTACK instead of a curly-brace array?

Use `VSTACK` when you're combining ranges from multiple source tabs that might grow independently. Curly-brace arrays (`{range1; range2}`) work well for static, equally-sized ranges you control and don't expect to change. In a multi-tab model where different tabs get updated on different cadences - say, P&L actuals through Q2 but Headcount data only through Q1 - `VSTACK` handles the mismatch gracefully by padding with `#N/A` instead of throwing an `array_literal` error. Available in Google Sheets since late 2023.

Why did the array_literal error appear after extending a date range on one tab?

Because the ranges in your curly-brace array are no longer the same length. If the P&L tab now covers 36 months (B2:AK2) but the Headcount tab still stops at 24 months (B2:Y2), the formula `={'P&L'!B2:AK2; 'Headcount'!B2:Y2}` will throw the error because row 1 has 36 columns and row 2 has 24. The durable fix is keeping all source tabs aligned to the same column structure, driven by a shared `numPeriods` assumption. The quick fix is trimming the longer reference to match the shorter one, or switching to `VSTACK` which will pad the mismatch with `#N/A` instead of erroring.

What's the difference between the array_literal error and #VALUE! in Google Sheets?

`#ERROR!` (array_literal) is a parse-time failure: Sheets can't interpret the formula's syntax before running it. `#VALUE!` is a runtime failure: the formula is syntactically valid but produces an incompatible data type during evaluation - like passing text where a number is expected. Array literal errors appear immediately when you type the formula, regardless of cell dependencies. `#VALUE!` requires the formula to run and fail. Knowing the distinction matters because the fixes are different: `array_literal` requires structural changes to the formula; `#VALUE!` is often fixable with `VALUE()` conversion or type checking.

array_literal Error Google Sheets: Causes & Fixes (2026)

The fix depends on what caused the mismatch: pad the shorter dimension to match the longer one, restructure the formula to avoid jagged ranges, or replace the literal with VSTACK/HSTACK (available since late 2023).

What the array_literal Error Actually Means

In Google Sheets, curly braces build arrays inline. Commas separate columns within a row; semicolons separate rows within an array. So ={1,2,3} creates a 1×3 horizontal array, and ={1;2;3} creates a 3×1 vertical array.

The array_literal error appears the moment the grid isn't rectangular. If row 1 has 3 columns and row 2 has 2, Sheets doesn't know how to fill the gap - it throws #ERROR! immediately. No partial rendering, no fallback.

={1,2,3; 4,5}    → #ERROR! (row 2 is missing one element)
={1,2,3; 4,5,6}  → works fine

This is different from a runtime error like #VALUE!. The array_literal error happens at parse time - Sheets won't even attempt to evaluate the formula. IFERROR can't catch it. You fix it or you don't.

Where the array_literal Error Bites Multi-Tab Models

The error is trivial in toy examples. It gets painful in a real model.

The most common trigger: combining ranges from tabs that have grown at different rates. Imagine your board pack has a P&L tab with 36 months of actuals (columns B:AK) and a Headcount tab added later that only covers 24 months (columns B:Y). You write a summary table on the Returns tab:

={'P&L'!B4:AK4; 'Headcount'!B12:Y12}

Row 1 has 36 elements. Row 2 has 24. #ERROR!.

The same thing breaks contribution margin analyses where some SKUs launched partway through the year, cohort tables where early cohorts have more periods, and any sensitivity table that pulls ranges of different lengths from separate assumption tabs. A DCF model that combines unlevered FCF (36 periods) with terminal value assumptions (1 cell padded out) hits this constantly.

The insidious version: it works fine for 18 months, then someone extends the P&L to cover Q3 actuals and the summary tab silently breaks. The array_literal error doesn't cascade - it's not a reference error, it's a parse failure - so you only catch it when you look directly at the cell.

How to Fix the array_literal Error in Google Sheets

There are 4 workable approaches, each with real trade-offs.

Fix	When to use	Trade-off
Anchor both ranges to the same fixed range	Dimensions are stable and known	Creates maintenance debt as model grows
Pad shorter range with blank literals	Quick one-off fix	Gets unreadable fast; avoid in production
Switch to VSTACK/HSTACK	Ranges may diverge over time	Pads mismatches with `#N/A` instead of blank
Restructure source tabs to enforce consistent column layout	Long-lived, multi-analyst models	Upfront work, no ongoing error risk

Option 1: Anchor to a fixed range

If both ranges should cover the same span, hardcode the shorter one to match:

={'P&L'!B4:AK4; 'Headcount'!B12:AK12}

Empty cells in Headcount return blank, which is fine for most outputs. The problem is maintenance: when the model extends to 48 months, you update one range and forget the other, and you're back here.

Option 2: Use VSTACK (recommended)

=VSTACK('P&L'!B4:AK4, 'Headcount'!B12:Y12)

VSTACK pads the shorter row with #N/A rather than erroring. Wrap the output in IFERROR where you need clean zeros:

=IFERROR(
  VSTACK('P&L'!B4:AK4, 'Headcount'!B12:Y12),
  0
)

For a cash flow bridge pulling from 3 source tabs with slightly different period counts, this is the cleanest approach available:

=VSTACK(
  'EBITDA'!C5:N5,
  'Capex'!C8:N8,
  'WorkingCapital'!C12:N12
)

Option 3: Enforce consistent column structure

The permanent fix. Every tab in the model references the same startDate and numPeriods from an Assumptions tab:

=SUMIFS('P&L'!C:C, 'P&L'!B:B, ">="&Assumptions!$B$3, 'P&L'!A:A, "Revenue")

When all ranges are built off the same period count, the dimensional mismatch can't happen. Thirty minutes to set up, and the next analyst who opens the file doesn't need to debug array_literal errors.

VSTACK and HSTACK: When They're Worth It

VSTACK stacks rows vertically; HSTACK stacks columns horizontally. Both were added to Google Sheets in late 2023 as part of the Lambda helper functions rollout. As of July 2026, they're available in all Google Workspace tiers including the free consumer version.

The key behavioral difference from curly-brace arrays: instead of erroring on dimensional mismatches, VSTACK/HSTACK pad the short dimension with #N/A. For a bank syndicate DCF where the debt schedule (60 months) and the operating model (48 months) have different period lengths, that padding behavior means the formula at least runs - you just clean up the #N/A cells with IFERROR.

One gotcha: VSTACK isn't available in Excel Online without a Microsoft 365 subscription (Excel added these functions in 2022, but older file formats don't support them). If you're sharing models across Sheets and Excel, test before shipping.

Edge Cases Worth Knowing

Whole-column references: ={A:A; B:B} used to throw array_literal errors when the two columns had data in different row counts. Since mid-2024, Google Sheets handles open-ended column references more gracefully. But mixing a full-column reference with a specific range - ={A:A; B1:B847} - still errors because the mismatch is explicit.

Regional locale differences: In German, French, and Portuguese locale settings, the separator characters shift. Commas become semicolons; semicolons become backslashes. The array_literal error still fires for dimensional mismatches, but the syntax looks different. Models shared across regions can hit confusing "works on my machine" failures.

Excel import: Excel's CSE array formulas (Ctrl+Shift+Enter) use {…} syntax but behave differently from Sheets array literals. When you open an Excel file in Sheets, some of these get rewritten and occasionally produce array_literal errors that didn't exist in the original file.

ModelMonkey's formula inspection catches dimensional mismatches before they propagate - if you're assembling a board pack across 8+ linked tabs, having something flag the mismatch in Headcount before it shows up as #ERROR! in the Returns summary saves a debugging session. Try ModelMonkey free for 14 days - it works in both Google Sheets and Excel.