> ## Documentation Index
> Fetch the complete documentation index at: https://docs.binarly.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Code Size Limit

> How the code size limit decides which binary components the Binarly Analysis Engine analyses, and where components excluded from analysis are reported.

The Binarly Analysis Engine caps how much code a single binary component may contain before analysis skips it. A component over the cap is still unpacked and listed with its name and path, but its code is not analysed, so no code-derived findings are produced for it.

Memory and scan time depend on the size of the individual components in an image. The limit is therefore a tested value set per deployment, not a fixed platform constant, and it can be reviewed for your workload.

## What code size means

Code size is the amount of executable code in a component as it would be loaded into memory. It is not the file size on disk, and it does not include data sections.

| Format                     | Code size is                                                                                                                                 |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| ELF                        | The sum of the memory sizes of all executable program headers. When a binary has none, the allocated executable sections are summed instead. |
| PE                         | The sum of the virtual sizes of all sections marked as code or executable.                                                                   |
| TE (UEFI terse executable) | The sum of the virtual sizes of all sections marked as code or executable.                                                                   |

A component with no executable sections has a code size of zero and is never excluded, however large the file is.

The limit applies only to components the platform classifies as binary code. Components on non-binary platforms are analysed regardless of size.

## What happens to an excluded component

The component keeps its place in the scan results. What changes is analysis coverage:

* Analysis tools that hit the limit skip the component and produce no findings from its code.
* The scan records a `metadata/analysis/exceeds-code-size-limit` property against the component, carrying its actual code size and the limit it exceeded. See [Metadata Classes](/resource-center/finding-classes#metadata-classes) for where this class sits.
* The component still appears in the component tree with its name and path.

Coverage is reduced rather than absent, because the limit can be configured per analysis tool. A component can be over one tool's limit and under another's, in which case the tools with the higher limit still analyse it.

## Finding excluded components

In the platform UI, the Components tab on an image carries the configured limit in its tooltip, and its **Reduced analysis coverage** tab lists every component that was skipped, with a count next to the tab label. Each row shows the component name, its code size, its path, and the reason it was excluded. Name and path filter on substrings, and code size sorts. When nothing was skipped the tab is empty and disabled. The upload dialog states the limit before you submit a file. See [Components tab](/user-guides/image-scans/all-about-details#components-tab) for the walkthrough.

The tooltip and the upload notice state the limit from your instance configuration. The Reason column on each row shows the limit that component was measured against, which can be lower where an individual analysis tool is configured differently.

The same list is available from the components grid endpoint by filtering on the exclusion reason:

```bash theme={null}
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": [
      {"field": "productId", "value": "'"$BINARLY_PRODUCT_ID"'", "comparator": "equals"},
      {"field": "imageId", "value": "'"$IMAGE_ID"'", "comparator": "equals"},
      {"field": "reason", "value": ["exceedsCodeSizeLimit"], "comparator": "in"}
    ]
  }' \
  "${BINARLY_API_URL}/api/v4/grids/components:gridList"
```

Each returned row carries `codeSize` and `codeSizeLimit` in bytes alongside `reason`. All three are absent for components that were analysed in full.

## If you need more coverage

Binarly sets the limit to a tested value that keeps scans within the resourcing an instance is provisioned for. If components you care about show up under Reduced analysis coverage and you need them analysed, contact [Binarly Support](/user-guides/about/customer-support) with the image and the components in question, and we will review the limit for your workload.

Self-hosted operators set the value themselves. See [Analysis Code Size Limit](/on-prem/v3/considerations#analysis-code-size-limit) for the chart value, the default, and the resourcing to account for before raising it.

## Related

* [Components tab](/user-guides/image-scans/all-about-details#components-tab) - Reviewing components and reduced analysis coverage in the UI
* [Finding Classes Reference](/resource-center/finding-classes#metadata-classes) - Where the code size limit metadata class sits
* [Analysis Code Size Limit](/on-prem/v3/considerations#analysis-code-size-limit) - Setting the limit in a self-hosted deployment
* [Component and Version Identification](/resource-center/component-identification) - How components are identified before any code analysis runs