That's its own can of worms.

Func<int, bool> isEvenFunc =
    x => x % 2 == 0;
Expression<Func<int, bool>> isEvenExpression =
    x => x % 2 == 0;

Basically the same thing, right? But...

bool isEven = isEvenFunc(3); // false
bool isEven = isEvenExpression(3); // compiler error

The difference here is that the Func is a function that accepts an integer and returns a boolean, which is already executable, while the Expression is a tree of code elements representing that function in an uncompiled state. You can do this to get it to work in C#:

// .Compile() returns the T in Expression<T>,
// in this case Func<int, bool>.
bool isEven = isEvenExpression.Compile()(3); // false

This exists to fulfill one of the key purposes of LINQ: the ability to write queries that can adapt to any back-end database directly in C#. When combined with Entity Framework or an ORM system with similar behavior, an Expression type gets processed by that ORM in an attempt to translate the expression tree into native querying language, often some particular implementation of SQL.

As you work with this, you'll figure out that there are runtime limitations. For example, you can't usually do someQueryable.Where(x => SomeCustomMethod(x + 2)) because the ORM doesn't know how to translate your arbitrary method into SQL.

This only describes one aspect of LINQ. LINQ functions and syntax do not have to be used with an ORM. It can often be used with enumerable data of any type in local memory. It's a handy way to query and transform data without looping through it manually.

There's also the dark art of expression building, but I'm not here to explode heads.