Introduction

Most TensorFlow to TensorFlow.js conversion failures come from one of three issues: the SavedModel export is incomplete, the converter cannot map one or more operations, or the wrong signature is being converted. The fastest way to debug the problem is to inspect the SavedModel first, then run the converter with an explicit command instead of guessing.

Start by Verifying the SavedModel

Before blaming TensorFlow.js, make sure the SavedModel itself is valid. A usable export should contain saved_model.pb, a variables directory, and at least one signature that defines how inference should run.

This command shows the available signatures:

saved_model_cli show \
  --dir ./saved_model \
  --all

Look for the serve or serving_default signature and confirm the input and output tensor names. If the SavedModel is malformed, the TensorFlow.js converter cannot recover from that.

A clean export from Keras looks like this:

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Input(shape=(4,)),
5    tf.keras.layers.Dense(8, activation="relu"),
6    tf.keras.layers.Dense(3, activation="softmax"),
7])
8
9model.compile(optimizer="adam", loss="sparse_categorical_crossentropy")
10model.export("saved_model")

If you are exporting from older TensorFlow code, you may still see:

model.save("saved_model")

Either way, verify the output on disk before converting it.

Use the Converter Explicitly

Once the SavedModel checks out, run the TensorFlow.js converter with the correct input format:

1tensorflowjs_converter \
2  --input_format=tf_saved_model \
3  --output_format=tfjs_graph_model \
4  --signature_name=serving_default \
5  --saved_model_tags=serve \
6  ./saved_model \
7  ./web_model

That command avoids two common mistakes:

• forgetting to name the signature
• converting the wrong tag set

If conversion succeeds, the output directory contains model.json and one or more binary weight shard files.

To confirm the result in JavaScript:

1import * as tf from "@tensorflow/tfjs";
2
3async function main() {
4  const model = await tf.loadGraphModel("file://./web_model/model.json");
5  const input = tf.tensor2d([[0.1, 0.2, 0.3, 0.4]]);
6  const output = model.predict(input);
7  output.print();
8}
9
10main();

That example is for a Node.js environment. In a browser, use a normal URL instead of a file:// path.

Unsupported Operations Are a Frequent Cause

A SavedModel can be valid and still fail conversion because TensorFlow.js does not implement every TensorFlow operation. This usually shows up as an error mentioning an unsupported op name.

At that point, you have four options:

1. simplify the model architecture
2. export a model that uses only supported layers
3. convert from a Keras format if that path fits the model better
4. keep inference on the server instead of in TensorFlow.js

For example, custom layers that depend on low-level TensorFlow ops are more likely to fail than a plain Keras model made of standard dense, convolutional, pooling, and activation layers.

If you control the original model code, reduce the model to the smallest version that still reproduces the converter failure. That makes unsupported ops much easier to spot.

Version Mismatches Also Matter

The Python package versions involved in export and conversion need to be reasonably aligned. Strange errors can come from using a very new TensorFlow SavedModel with an older TensorFlow.js converter, or the reverse.

A quick environment check:

1python - <<'PY'
2import tensorflow as tf
3import tensorflowjs as tfjs
4
5print("tensorflow:", tf.__version__)
6print("tensorflowjs:", tfjs.__version__)
7PY

If conversion started failing after an upgrade, try reproducing the export and conversion in a clean virtual environment. That often separates a real model incompatibility from a broken local installation.

Check the Signature and Input Shapes

Another common error is converting the wrong callable endpoint. Some SavedModels expose multiple signatures, and the default one may not match what you expect.

For example, suppose saved_model_cli shows an input tensor with shape (None, 224, 224, 3). If your inference code later feeds a flat vector, the model may load but not run correctly. Signature inspection tells you exactly what the converter is packaging.

For subclassed models, be especially careful. If the model was never traced with a stable input signature before export, the saved artifacts may not be what you think they are.

Common Pitfalls

The biggest pitfall is trying to convert a directory that is not actually a SavedModel export. A folder containing only checkpoints or a .keras file is not the same thing.

Another one is ignoring the signature information. Conversion commands without --signature_name and --saved_model_tags can work, but explicit values are safer and easier to debug.

Users also often assume every TensorFlow op is supported in TensorFlow.js. That is not true. If the error names an unsupported op, the fix is usually architectural, not just a command-line flag.

Finally, avoid debugging blind. Inspect the SavedModel with saved_model_cli, record package versions, and reduce the model to the smallest failing example. That process is much faster than repeatedly rerunning the converter with random options.

Summary

• Verify the SavedModel structure and signatures before converting it.
• Use tensorflowjs_converter with explicit input format, signature name, and tag values.
• Unsupported ops are a common source of conversion failure.
• Check TensorFlow and TensorFlow.js package versions when errors seem inconsistent.
• Inspect shapes and signatures carefully so the exported model matches your real inference path.