Introduction

The difference between keras and tf.keras depends partly on which generation of the ecosystem you are using. Historically they were distinct packages with different release cycles, but in current TensorFlow releases the line is much thinner because TensorFlow exposes Keras directly under the tf.keras namespace.

Historical Difference

Originally, Keras was a standalone high-level neural network library that could run on multiple backends. tf.keras was TensorFlow's bundled implementation of the Keras API. That meant you had two practical choices:

• install standalone Keras separately
• use the copy shipped inside TensorFlow

In that older model, the biggest differences were packaging and compatibility. Standalone Keras could move on its own schedule, while tf.keras was versioned with TensorFlow.

What the Relationship Looks Like Now

In current setups, keras is the standalone package and tf.keras is the TensorFlow namespace that exposes Keras for TensorFlow users. With TensorFlow 2.16 and later, the official Keras docs note that installing TensorFlow gives you Keras 3 by default through both import keras and from tensorflow import keras.

That means the practical difference today is often not the public API you type, but the environment and execution model around it.

Use keras when you want the standalone package explicitly and may want multi-backend workflows. Use tf.keras when you are writing TensorFlow-centric code and want the familiar TensorFlow namespace.

The Main Differences That Still Matter

Package Ownership and Versioning

keras is installed as its own package. tf.keras comes through TensorFlow. If you pin TensorFlow tightly, you are indirectly pinning the Keras implementation exposed by tf.keras as well.

Backend Scope

Modern Keras supports multiple backends, including TensorFlow, JAX, and PyTorch. tf.keras is specifically the TensorFlow-facing namespace. If your project is designed to stay inside the TensorFlow ecosystem, tf.keras is a natural fit. If you want a codebase that can target different backends, the standalone keras package is the clearer choice.

TensorFlow-Specific Features

TensorFlow guides, older examples, and many production codebases still use tf.keras because it sits naturally beside tf.data, tf.distribute, TensorBoard callbacks, SavedModel export, and other TensorFlow APIs. Even when the layer and model code looks the same, the surrounding tooling often determines which import style is more convenient.

Example Imports

In many current environments these imports behave similarly:

1import tensorflow as tf
2import keras
3from tensorflow import keras as tfk
4
5print("TensorFlow:", tf.__version__)
6print("Standalone Keras:", keras.__version__)
7print("tf.keras version:", tfk.__version__)

A simple model definition is nearly identical either way:

1import keras
2
3model = keras.Sequential([
4    keras.layers.Input(shape=(20,)),
5    keras.layers.Dense(32, activation="relu"),
6    keras.layers.Dense(1, activation="sigmoid"),
7])
8
9model.compile(optimizer="adam", loss="binary_crossentropy")

Or with the TensorFlow namespace:

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Input(shape=(20,)),
5    tf.keras.layers.Dense(32, activation="relu"),
6    tf.keras.layers.Dense(1, activation="sigmoid"),
7])
8
9model.compile(optimizer="adam", loss="binary_crossentropy")

The visible code is almost the same. The bigger question is which ecosystem contract you want your project to depend on.

What About Legacy Keras 2?

Some older projects still depend on legacy Keras 2 behavior. The Keras documentation explains that this legacy line is available as tf_keras. That matters when reviving an older TensorFlow project that breaks after a modern dependency upgrade.

If a legacy codebase assumes old serialization behavior or deprecated APIs, forcing it onto the latest stack may create unnecessary migration work. In that case, the real choice is not keras versus tf.keras, but modern Keras versus legacy Keras.

Which One Should You Prefer?

For new TensorFlow-first code, using tf.keras is still completely reasonable because it matches TensorFlow tutorials and integrates cleanly with the rest of the framework.

For new code that wants backend flexibility or wants to follow the standalone Keras project directly, prefer keras.

The important point is consistency. Pick one import style for a codebase and stick to it. Mixing both casually can confuse readers and complicate environment management.

Common Pitfalls

The most common mistake is assuming blog posts from different years describe the same ecosystem. Keras has changed significantly, so advice from the Keras 2 era can be misleading in a Keras 3 environment.

Another mistake is mixing keras and tf.keras imports in the same project without a reason. Even if the code runs, it obscures which package versions the project actually depends on.

Legacy migrations are another source of pain. If an old project breaks after a TensorFlow upgrade, check whether it really expects legacy Keras 2 behavior before patching errors one by one.

Summary

• 'keras is the standalone Keras package.'
• 'tf.keras is the TensorFlow namespace for Keras.'
• In modern TensorFlow versions, both often expose the same Keras 3 API surface.
• The main differences are packaging, versioning, backend scope, and migration behavior.
• Choose tf.keras for TensorFlow-centric projects and keras for clearer standalone or multi-backend workflows.