# Upload errors, decoded

Every error LumiDevKit can show you on upload, what actually causes it, and the fix. Find your message below.

[[img:troubleshooting-uploads/01-error.png|An upload error in place. It appears under the card you actually used and nowhere else, so on a screen with several drop zones you can tell which one refused the file. The link under it lands on the matching section here, for the messages we have written up.]]

## Please upload a .json, .bubble, or .sql file

The file extension is not one LumiDevKit accepts.

The Database Visualizer takes `.json`, `.bubble` and `.sql`. The other tools take `.json` and `.bubble`.

Renaming works, but the extension is not cosmetic: it picks the parser. A `.sql` file goes to the SQL parser and everything else goes to the JSON one, and that choice is made before either of them looks inside the file. So renaming a Postgres dump to `.json` does not help, it just fails differently. Only text pasted into the box is judged by its content.

## File is too large (max 50MB)

The hard limit is 50 MB.

Two things to try:

- Run the file through the [JSON Sanitizer](/docs/json-sanitizer) first. It deletes all of `settings.secure` and the credential-bearing keys under `settings.client_safe`, so it helps most when a plugin or API Connector block is what made the file heavy. Your pages, workflows and element definitions pass through untouched, so on a big app export the saving may not be enough on its own.
- For the Database Visualizer specifically, you do not need the whole app. Any file with a `user_types` key works, so a previously downloaded schema JSON is far smaller.

Every uploader says so when it refuses a file, so a drop zone that appears to do nothing at all is worth reporting rather than a size or extension problem on your end.

The JSON Sanitizer is the one tool with no size limit, and that is deliberate: this page sends you there as the fix for hitting the limit elsewhere, so capping it too would be circular.

## No database types found

Full text: *"No database types found. Upload a Bubble app/schema export (.json) or a Postgres schema (.sql)."*

The file parsed fine, but it has no `user_types` key at the top level.

Causes, most common first:

- You uploaded something that is not a Bubble export at all.
- The JSON has `user_types` nested inside another object. Only the top level is checked.

If an AI wrapped its JSON in explanation you get a different message, not this one, because the file never parses at all. See [Unexpected token … is not valid JSON](#unexpected-token-is-not-valid-json).

See [the schema format](/docs/schema-format-for-ai) for exactly what the file must look like.

## Invalid Bubble schema format. Expected user_types object

You will not see this from an upload. The importer checks for `user_types` before the store does, so a file without it produces *"No database types found"* above and stops there. What reaches this section in practice is the shorter *"Invalid schema format."*, shown when a **saved** schema no longer parses.

Note that `"user_types": {}` is *accepted*. An empty object is valid and gives you a diagram with just the built-in User on it. If that is what you are seeing, your file parsed correctly and genuinely contains no data types. An array is accepted for the same reason, since the only test is that the value is an object and an array is one.

## Invalid Bubble JSON format. Expected workflow data

From the [Workflow Tracer](/docs/workflow-tracer). The file has none of `pages`, `element_definitions` or `api`.

Almost always this means you uploaded a database-only schema file instead of a full application export. See [which file does each tool need?](/docs/which-export-does-each-tool-need).

## No workflows found in the uploaded file

The file is a valid application export, but nothing in it defines a workflow. Check you exported the right app.

## Invalid Bubble JSON format. Expected pages and/or element_definitions

From the [Reusables Tree](/docs/reusables-tree). Same cause as the workflow message: you need a full application export.

## Invalid Bubble JSON format. Expected pages or element_definitions

From the [Audit](/docs/audit) tool. Same cause again.

## Invalid Bubble JSON format. Expected pages or element_definitions with styles

From the [Design System](/docs/design-system) tool. The message overstates the requirement: the check behind it is the same one the Audit and Reusables Tree run, and it only fails when the file has neither `pages` nor `element_definitions`. A file with no `styles` parses fine, it simply has no named styles to report.

If you sanitized the file with a tool other than ours, it may have stripped `styles` or `settings`. That will not trigger this error, but a missing `styles` block leaves the style names empty, and a missing `settings` block costs you the editor's own colour and font tokens and the app's custom breakpoint sizes. Bubble's eight built-in breakpoints still show either way. LumiDevKit's own [JSON Sanitizer](/docs/json-sanitizer) deliberately preserves the design-related keys.

## No pages or reusables found in the uploaded file

From the [Reusables Tree](/docs/reusables-tree) and the Design System. The file cleared the `pages` / `element_definitions` check, but neither key holds anything the tool can draw.

A real Bubble export cannot produce this. Every export carries its pages, and the [JSON Sanitizer](/docs/json-sanitizer) keeps them, so the file is hand-made, AI-generated or hand-edited with an empty or mistyped `pages` block.

The two tools disagree at the edges. The Reusables Tree skips a page entry whose `type` is set to anything other than `Page`, while the Design System does not filter on type at all, so the same file can come up empty in one and load fine in the other.

## No findings for this action in the uploaded file

From the [Audit](/docs/audit) tool. **This is good news.** The check ran and found nothing wrong. It is phrased as an error because it appears in the same slot; it does not mean anything failed.

## Invalid JSON file. Please check the file and try again

From the [JSON Sanitizer](/docs/json-sanitizer). The file is not valid JSON at all.

The usual cause is a truncated download or a partial copy-paste. Worth knowing: the Sanitizer is the one uploader that does **no** repair. The others quietly fix a missing opening brace, a single trailing comma and unbalanced closing braces before giving up, so a file that loads elsewhere in LumiDevKit can still fail here, and one missing brace is enough.

## JSON must be an object with keys. This file has an unexpected format

From the [JSON Sanitizer](/docs/json-sanitizer). The file is valid JSON but is an array or a bare value rather than an object.

## JSON file appears to be truncated or malformed

The file ended mid-structure. Re-export it from Bubble and make sure the download completed.

## Unexpected token … is not valid JSON

This one is not LumiDevKit's message, it comes from the browser's own JSON parser, so the exact wording varies: *"Unexpected token 'H', "Here is yo"... is not valid JSON"*.

Read the snippet the message quotes, because it tells you which of two different problems you have.

**The snippet starts at the beginning of the file.** The content is not JSON from the very first character, and the usual cause is text wrapped around it: an AI's reply copied along with its explanation, or with the ```` ```json ```` fence still attached. Delete everything before the first `{` and everything after the last `}`. LumiDevKit repairs a few kinds of truncation, but it never strips a preamble.

**The snippet opens with `...`.** The file is fine up to that point and breaks further in, so trimming the ends will not help. The usual cause is a value JSON does not allow, left behind by whatever wrote the file: `True`, `None` or `undefined` where JSON needs `true`, `null` or a real value. Fix that value instead.

## Could not parse SQL

Full text includes the underlying parser's message, usually with a line number: *"missing ')' at ';' (near line 4)"*. A few arrive without one, because the parser crashed rather than reporting a diagnostic. A column written with no type at all is the common case.

Some of these messages are very long. A trailing comma in a table body makes the parser list every keyword it would have accepted at that point, which runs to thousands of characters. Only the useful part is shown; **Show full message** has the rest if you want it.

LumiDevKit parses **Postgres only**. `CREATE TABLE` and `CREATE TYPE … AS ENUM` define the diagram. Foreign keys are read whether they are written inline as `REFERENCES table(column)` or added later with `ALTER TABLE … ADD CONSTRAINT … FOREIGN KEY`, and both produce the same relationship. On top of those come `ALTER TABLE … ADD CONSTRAINT … PRIMARY KEY`, inline `CHECK (col IN (…))`, `INSERT INTO … VALUES` seed rows and LumiDevKit's own `COMMENT ON` markers. Everything else, indexes and policies included, is ignored rather than rejected.

That makes this error narrower than it sounds. It fires when a `CREATE TABLE` or a `CREATE TYPE … AS ENUM` statement cannot be read:

- The column syntax is not Postgres, but is close enough to reach the parser. `AUTO_INCREMENT` and `AUTOINCREMENT` are the usual ones.
- The table body is malformed *and* a closing `);` still appears further down, which is what happens when a truncated paste runs into the next `CREATE TABLE`. A paste that simply stops mid-table gives no error at all: only complete `CREATE TABLE … );` statements reach the parser, so the unfinished one is dropped and that table is quietly missing from the diagram.

A MySQL or SQL Server dump that quotes its identifiers with backticks or brackets never reaches the parser at all, so it gives you an empty diagram rather than this error. A data dump with no `CREATE TABLE` in it does the same.

See [import a Postgres schema](/docs/import-a-postgres-schema).

## Please log in to see your saved schemas

Not what it sounds like. You cannot reach the saved-schema list while signed out, because you are sent to the login page before the page ever loads.

So this means the tab was already open when the session ended: you signed out in another tab, or the cookies were cleared. The open page has no way to know that until it asks the server. Reload and sign in again.

## The file uploaded, but the diagram looks wrong

No error message, but the result is not what you expected. This is the most important section on the page, because the schema parser does not reject bad input — it renders it.

- **Red `[Missing: X]` boxes** — a field references a type that does not exist.
- **A box labelled `undefined`** — that data type has no `display`. Data types have no fallback, unlike option sets, which fall back to their key.
- **A list field with no relationship line** — the type string was not recognised, most often `list.user` where it should be `list.custom.user`.
- **Fewer types than expected** — two of them collided on the same key.
- **A type you know exists is absent** — it is marked deleted, and deleted items are hidden by default. Toggle *Show deleted*.

All of these are explained in [the schema format](/docs/schema-format-for-ai).

A `.sql` file behaves the same way. With no `CREATE TABLE` statements in it, it loads as an empty schema and draws a diagram with only the built-in User on it, rather than reporting an error. See [import a Postgres schema](/docs/import-a-postgres-schema).