---
title: "Conditions in the TypoScript syntax"
manual: "TypoScript Explained"
version: "13.4"
permalink: "https://docs.typo3.org/permalink/t3tsref:typoscript-syntax-conditions-examples@13.4"
source: "Syntax/Conditions/Index.rst"
rendered: "2026-09-19T07:15:48+00:00"
---

# Conditions in the TypoScript syntax {#typoscript-syntax-conditions-examples}

TypoScript can contain `if` and `if / else` control structures. They
are called `conditions`, their "body" is only considered if a condition criteria
evaluates to true. Examples of condition criteria are:

-   Is a user logged in?
-   Is it Monday?
-   Is the page called in a certain language?

Conditions are a TypoScript syntax construct. They are thus available in both
frontend TypoScript and backend TSconfig. However, condition criteria are based
on prepared variables and functions, and those are different in frontend
TypoScript and backend TSconfig. For example, the `frontend` variable does
not exist in TSconfig, it is (obviously) impossible to have a backend TSconfig
condition that checks for a logged in frontend user.

**Table of contents**

-   [Basic usage of TypoScript conditions](https://docs.typo3.org/permalink/t3tsref:basic-usage-of-typoscript-conditions@13.4)
-   [Syntax and rules](https://docs.typo3.org/permalink/t3tsref:syntax-and-rules@13.4)
-   [Allowed criteria in TypoScript conditions](https://docs.typo3.org/permalink/t3tsref:allowed-criteria-in-typoscript-conditions@13.4)
-   [TypoScript conditions and the Symfony expression language](https://docs.typo3.org/permalink/t3tsref:typoscript-conditions-and-the-symfony-expression-language@13.4)

## Basic usage of TypoScript conditions {#typoscript-syntax-conditions-usage}

**packages/my_site_package/Configuration/TypoScript/setup.typoscript**

```typoscript
page = PAGE
page.10 = TEXT
page.10.value = HELLO WORLD!

[frontend.user.isLoggedIn]
page.20 = TEXT
page.20 {
  value = A frontend user is logged in.
}
[GLOBAL]

```

## Syntax and rules {#typoscript-syntax-conditions-syntax}

These general rules apply:

### General condition syntax {#typoscript-syntax-syntax-conditions}

Conditions are encapsulated in `[` and `]`

### `[GLOBAL]`, `[ELSE]` and `[END]` {#typoscript-syntax-end-condition}

`[ELSE]` negates a previous condition criteria and can contain
a new body until `[END]` or `[GLOBAL]`. `[ELSE]`
is considered if the condition criteria did *not* evaluate to true.

`[END]` and `[GLOBAL]` stop a given condition scope.
This is similar to a closing curly brace `}` in programming languages like PHP.

**packages/my_site_package/Configuration/TypoScript/setup.typoscript**

```typoscript
[date("j") == 9]
page.10.value = It is the 9th day of the month!
[ELSE]
page.10.value = It is NOT the 9th day of the month!
[END]

```

Conditions automatically stop at the end of a text snippet (file or record), even
without `[END]` or `[GLOBAL]`. Another snippet on the same
level is in "global" scope automatically. The backend TypoScript and
TSconfig modules may mumble about a not properly closed condition, though.

<!-- TODO: no Markdown rendering for "versionchanged" -->

[END] and [GLOBAL] behave exactly the same. Both
are kept for historical reasons (for now).Conditions automatically stop at the end of a text snippet (file or record).

### Combining multiple TypoScript conditions with `and` or `or` {#typoscript-syntax-end-condition-or}

Multiple condition criteria can be combined using `or` or `||`,
as well as `and` or `&&`

**packages/my_site_package/Configuration/TypoScript/setup.typoscript**

```typoscript
# "or" is an alias for "||": one of the criteria is enough
[frontend.user.isLoggedIn || ip('127.0.0.1')]
page.20 = TEXT
page.20 {
  value = A frontend user is logged in, or the browser IP is 127.0.0.1
  stdWrap.case = upper
}
[GLOBAL]

# "and" is an alias for "&&": both criteria must apply
[frontend.user.isLoggedIn && siteLanguage("languageId") == 1]
  page.30 = TEXT
  page.30.value = A logged in frontend user browses the second site language
[GLOBAL]

```

Single criteria can be negated using `not` or `!`

**packages/my_site_package/Configuration/Sets/Main/setup.typoscript**

```typoscript
page = PAGE
page.10 = TEXT
page.10.value = You are logged in

# This is hard to read
[frontend.user.isLoggedIn]
[ELSE]
page.10.value = You are *not* logged in
[END]

# This is faster to read
[!frontend.user.isLoggedIn]
page.10.value = You are *not* logged in
[END]

```

As in most programming languages, `not` binds more strongly than
`and`, which in turn binds more strongly than `or`. Use
parentheses whenever the intended grouping is not the default one:

**packages/my_site_package/Configuration/Sets/Main/setup.typoscript**

```typoscript
# Reads as: isLoggedIn or (languageId == 1 and not ip('127.0.0.1'))
[frontend.user.isLoggedIn || siteLanguage("languageId") == 1 && !ip('127.0.0.1')]
  page.40 = TEXT
  page.40.value = Default grouping
[GLOBAL]

# Parentheses enforce a different grouping
[(frontend.user.isLoggedIn || siteLanguage("languageId") == 1) && !ip('127.0.0.1')]
  page.50 = TEXT
  page.50.value = Grouping enforced by parentheses
[GLOBAL]

```

> [!WARNING]
> All criteria of a condition belong into *one* pair of square brackets.
> Chaining several bracketed conditions with `&&` or
> `||` was the syntax used before the Symfony expression
> language was introduced in TYPO3 v9. It has been removed since and now
> fails *silently*: everything after the first closing bracket is treated
> as a comment, so all criteria but the first one are ignored without any
> error message.

### TypoScript constant usage in Conditions {#typoscript-syntax-end-condition-constants}

Conditions can use constants. They are available in frontend TypoScript "setup" and
in TSconfig from "site settings". A simple example if this constant
`myPageUid = 42` is set:

```typoscript
[traverse(page, "uid") == {$myPageUid}]
    page.10.value = Page uid is 42
[end]
```

> [!NOTE]
> Using the [Null coalescing operator ??](https://docs.typo3.org/permalink/t3tsref:typoscript-syntax-syntax-null-coalescing@13.4)
> with constants used within conditions is not possible.

### Nesting conditions via TypoScript imports {#typoscript-syntax-end-condition-nesting}

Conditions can *not* be nested within code blocks.

**EXT:site_package/Configuration/Sets/Main/setup.typoscript**

```typoscript
# Invalid: Conditions must not be used within code blocks
# someIdentifier {
  #    someProperty = foo
  #    [frontend.user.isloggedIn]
  #       someProperty = bar
  #    [GLOBAL]
  # }

```

<!-- TODO: no Markdown rendering for "versionchanged" -->

Conditions *can* be nested into each other, if they are located in
different snippets (files or records), see example below. They can *not* be nested
within the same code snippet.

A second condition that is *not* `[ELSE]`, `[END]`
or `[GLOBAL]` *stops* a previous condition and starts a new one.
This is the main reason conditions can *not* be nested within one text snippet.

`@import` *can* be nested
inside conditions. This allows conditional includes and is a new feature of the
TYPO3 v12 parser.

### Using the null-safe operator in conditions {#typoscript-syntax-end-condition-null-save}

<!-- TODO: no Markdown rendering for "versionadded" -->

Using the null-safe operator is possible when accessing properties on objects
which might not be available in some context, for example `TSFE` in the
backend:

```typoscript
# Previously
# [getTSFE() && getTSFE().id == 123]

# Now
[getTSFE()?.id == 123]

```

## Allowed criteria in TypoScript conditions {#typoscript-syntax-syntax-value}

For a reference of allowed condition criteria, please refer to the according
chapter in the [frontend TypoScript Reference](https://docs.typo3.org/permalink/t3tsref:conditions@13.4) and
the [backend TSconfig Reference](https://docs.typo3.org/permalink/t3tsref:tsconfig-conditions@13.4). These references
come with examples for single condition criteria as well.

The TSconfig and TypoScript backend modules show lists of existing conditions
and allow simulating criteria verdicts to analyze their impact on the
resulting TypoScript tree.

## TypoScript conditions and the Symfony expression language {#typoscript-syntax-conditions-expression-language}

Condition criteria are based on
the [Symfony expression language](https://symfony.com/doc/current/components/expression_language/syntax.html).
The Core allows extending the Symfony expression language with own variables and
functions, see [symfony expression language API](https://docs.typo3.org/m/typo3/reference-coreapi/13.4/en-us/ApiOverview/SymfonyExpressionLanguage/Index.html#sel-within-typoscript-conditions)
for more details.
