Format SQL for Hibernate and Spring Boot — Free Browser Tool

Hibernate has a built-in SQL formatter that activates when you set hibernate.format_sql=true. It pretty-prints generated SQL in the application logs. The output is functional but has its own quirks: every clause on a new line whether you want it or not, sometimes excessive indentation, and no respect for line length. For sharing in PRs, runbooks, or post-mortems, the Hibernate output often needs additional cleanup.

Our browser tool produces cleaner output for the same queries. Copy the generated SQL from your Spring Boot logs, paste into the browser, get readable SQL you can share with the team. Also handles JPQL queries, @Query annotation strings, and raw SQL inside JdbcTemplate calls. No upload, runs in your browser.

Why hibernate.format_sql Output Often Needs More Work

Hibernate's built-in formatter (enabled by hibernate.format_sql=true) was added years ago and has not been updated. Common issues:

• Every JOIN on its own line, no exceptions. Even when JOINs are short, they get one per line, which makes simple queries look bigger than they are.
• Inconsistent indentation. Subqueries indent differently than top-level clauses, which can be confusing.
• No keyword case normalization. Hibernate preserves whatever case the entity manager generated, which can be a mix of upper and lowercase.
• Bind parameter placeholders are unreadable. The generated SQL has ? placeholders without the actual values. You have to enable logging.level.org.hibernate.type.descriptor.sql=TRACE to see the values, and the formatted output gets even messier.
• Long SELECT lists collapse. Hibernate puts the entire SELECT clause on one line, even with 30+ columns from JPA entity mappings.

The browser tool produces cleaner output: proper line breaks, consistent indentation, normalized case, and one-column-per-line for long SELECT lists.

Workflow for Reading Hibernate-Generated SQL During Debugging

1. Enable SQL logging in application.properties:
   spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql=TRACE
2. Reproduce the slow query in your dev environment.
3. Find the SQL in your application log — Hibernate prints it after the "Hibernate: " prefix.
4. Copy the SQL portion (without the Hibernate prefix or the parameter binding logs).
5. Paste into the browser SQL formatter.
6. Pick the dialect matching your database — PostgreSQL, MySQL, Oracle (Standard SQL), Transact-SQL.
7. Click Format for cleaner output than what Hibernate produced.
8. Run EXPLAIN on the formatted query in your database to understand the execution plan.

For complex queries with many JOINs and subqueries, the difference between Hibernate's formatting and the browser tool's output is significant.

Format SQL Inside Spring Data JPA @Query Annotations

Spring Data JPA repositories let you write custom queries with @Query annotations:

@Query("SELECT u FROM User u WHERE u.status = :status AND u.createdAt >= :from")

For short queries this is fine inline. For complex queries (5+ joins, subqueries, CASE expressions), the annotation string becomes unreadable. The fix:

1. Use Java text blocks (Java 15+) for multi-line @Query strings:
   @Query("""
  SELECT u FROM User u
  LEFT JOIN u.orders o
  WHERE u.status = :status
""")
2. Format the multi-line content in the browser before pasting into the text block.
3. Pick Standard SQL as the dialect — JPQL is similar enough to ANSI SQL that the formatter handles it cleanly. Entity names (User instead of users) pass through unchanged.

For Spring Boot 2.x projects on Java 8/11 (no text blocks), use string concatenation with line breaks. The result is uglier but functional.

Sell Custom Apparel — We Handle Printing & Free Shipping

JPQL vs Native SQL — Formatting Differences

JPQL is JPA's query language. It looks like SQL but uses entity names and field names instead of table names and column names. The browser formatter handles JPQL with the Standard SQL dialect:

What works:

• SELECT, FROM, WHERE, JOIN, ORDER BY, GROUP BY, HAVING — same syntax as SQL.
• JOIN FETCH for eager loading — formatted correctly.
• Subqueries — handled.
• Window functions (Hibernate 6+) — handled.
• CASE WHEN expressions — handled.

What is JPQL-specific:

• Entity references like User u instead of users u — pass through unchanged.
• Field navigation like u.address.city — pass through unchanged.
• JPA functions like SIZE(), INDEX(), TYPE() — pass through unchanged.
• Named parameters like :status — pass through unchanged.

The formatter does not validate JPQL — it does not know whether your entity names are correct. It just formats the structure. For validation, run the query in your IDE or against a test database.

Format Raw SQL Inside JdbcTemplate Calls

Spring JdbcTemplate is the escape hatch when you want raw SQL instead of JPA. The pattern:

jdbcTemplate.queryForList("SELECT id, name FROM users WHERE status = ?", "active")

For short queries this is fine. For complex queries the SQL string becomes long and unreadable. Same workflow:

1. Use a multi-line text block for the SQL string.
2. Format the SQL in the browser before pasting into the text block.
3. Pick the dialect matching your database.
4. Make sure parameter placeholders (?) survive — the formatter preserves them.

For very complex queries, consider extracting the SQL to a separate .sql file and loading it at runtime with StreamUtils.copyToString.

Spring Boot Configuration for Cleaner SQL Logging

Recommended Spring Boot config for working with SQL during development:

spring.jpa.show-sql=true — print SQL queries to the log
spring.jpa.properties.hibernate.format_sql=true — pretty-print (Hibernate's version)
spring.jpa.properties.hibernate.use_sql_comments=true — include source comments
logging.level.org.hibernate.SQL=DEBUG — log all SQL
logging.level.org.hibernate.type.descriptor.sql=TRACE — log parameter values

This produces verbose logs but lets you see exactly what queries Hibernate runs. For production, set these to higher levels (WARN, ERROR) — never leave SQL TRACE on in production.

For complex query analysis, copy the queries from the log into the browser formatter for cleaner output than Hibernate's built-in formatter produces.

Frequently Asked Questions

How is the browser formatter different from hibernate.format_sql?

Hibernate format_sql produces functional output but has its own quirks (every JOIN on its own line, inconsistent indentation, no case normalization). The browser formatter produces cleaner output for sharing, code review, and runbooks.

Can the browser formatter handle JPQL queries?

Yes. Pick Standard SQL as the dialect. JPQL is similar enough to ANSI SQL that the formatter handles it cleanly. Entity names and field navigation pass through unchanged.

Will it format SQL inside @Query annotations correctly?

Yes. Copy the SQL string content (without the @Query annotation syntax), format it, paste back. Use Java text blocks for multi-line @Query strings on Java 15+.

Should I disable hibernate.format_sql and use the browser tool instead?

Use both. Keep hibernate.format_sql enabled in dev for inline log readability. Use the browser tool for sharing or analyzing complex queries that need cleaner formatting.

Does the formatter preserve the ? bind parameters?

Yes. JDBC ? placeholders and JPQL named parameters (:name) are preserved during formatting. They are treated as opaque tokens.