{"id":93166,"date":"2022-01-20T21:01:53","date_gmt":"2022-01-20T21:01:53","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=93166"},"modified":"2026-03-09T12:37:47","modified_gmt":"2026-03-09T12:37:47","slug":"when-use-char-varchar-varcharmax","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/learn\/when-use-char-varchar-varcharmax\/","title":{"rendered":"CHAR vs VARCHAR vs VARCHAR(MAX) in SQL Server"},"content":{"rendered":"\n

Use CHAR<\/code> for fixed-length data like state codes, phone numbers, or postal codes where every value is the same length – it pads shorter values with spaces and uses consistent storage. Use VARCHAR<\/code> for variable-length data like names, addresses, or descriptions where lengths vary significantly – it stores only the characters entered plus 2 bytes of overhead.<\/p>\n\n\n\n

Use VARCHAR(MAX)<\/code> when you need to store strings longer than 8,000 bytes (up to 2 GB), typically for large text fields, XML fragments, or JSON documents. CHAR<\/code> is faster for fixed-width data; VARCHAR<\/code> is more space-efficient for variable data; VARCHAR(MAX)<\/code> has different storage and query plan behavior than standard VARCHAR<\/code>.<\/p>\n\n\n\n

Introduction<\/h2>\n\n\n\n

In every database, there are different kinds of data that need to be stored. Some data is strictly numeric, while other data consists of only letters or a combination of letters, numbers, and even special symbols. Whether it is just stored in memory or on disk, each piece of data requires a data type. Picking the correct data type depends on the characteristics of the data being stored. This article explains the differences between CHAR<\/code>, VARCHAR<\/code>, and VARCHAR(MAX)<\/code> in SQL Server.<\/p>\n\n\n\n

When selecting a data type for a column, you need to think about the characteristics of the data to pick the correct data type. Will each value be the same length, or will the size vary greatly between values? How often will the data change? Will the length of the column change over time? There might also be other factors, like space efficiency and performance, that might drive your decision on a data type.<\/p>\n\n\n\n

The CHAR<\/code>, VARCHAR<\/code>, and VARCHAR(MAX)<\/code> data types can store character data. This article will discuss and compare these three different character data types. The information found in this article will help you decide when it is appropriate to use each of these data types.<\/p>\n\n\n\n

CHAR the fixed-length character data type<\/h2>\n\n\n\n

The CHAR data type is a fixed-length data type. It can store characters, numbers, and special characters in strings up to 8000 bytes in size. CHAR<\/code> data types are best used for storing data that is of a consistent length. For example, two-character State codes in the United States, single-character sex codes, phone numbers, postal codes, etc. A CHAR<\/code> column would not be a good choice for storing data where the length varies greatly. Columns storing things like addresses or memo fields would not be suitable for a CHAR<\/code> column data type.<\/p>\n\n\n\n

This doesn\u2019t mean a CHAR<\/code> column can\u2019t contain a value that varies in size. When a CHAR<\/code> column is populated with strings shorter than the length of the column, spaces will be padded to the right. The number of spaces padded is based on the size of the column less the length of characters being stored. Because CHAR<\/code> columns are fully populated by adding spaces, when needed, each column uses the same amount of disk space or memory. Trailing spaces also make it a challenge when searching and using CHAR<\/code> columns. More on this in a moment.<\/p>\n\n\n\n

What is VARCHAR (variable-length character data type)?<\/h2>\n\n\n\n

VARCHAR<\/code> columns, as the name implies, store variable-length data. They can store characters, numbers, and special characters just like a CHAR<\/code> column and can support strings up to 8000 bytes in size. A variable-length column only takes up the space it needs to store a string of characters, with no spaces added to pad out the column. For this reason, VARCHAR<\/code> columns are great for storing strings that vary greatly in size.<\/p>\n\n\n\n

To support variable-length columns, the length of the data needs to be stored along with the data. Because the length needs to be calculated and used by the database engine when reading and storing variable-length columns, they are considered a little less performant than CHAR<\/code> columns. However, when you consider they only use the space they need, the savings in disk space alone might offset the performance cost of using a VARCHAR<\/code> column.<\/p>\n\n\n\n

Read also:<\/strong>
Temporary tables and data type selection in SQL Server<\/a>
AI embeddings in SQL Server 2025<\/a><\/p>\n\n\n\n

Differences between CHAR and VARCHAR data types<\/h2>\n\n\n\n

The fundamental difference between CHAR<\/code> and VARCHAR<\/code> is that the CHAR<\/code> data type is fixed in length, while the VARCHAR<\/code> data type supports variable-length columns of data. But they are also similar. They both can store alphanumeric data. To better understand the differences between these two data types, review the similarities and differences found in Table 1.<\/p>\n\n\n\n

Table 1: Differences between CHAR and VARCHAR<\/strong><\/p>\n\n\n\n

\n

CHAR<\/strong><\/p>\n<\/td>

\n

VARCHAR<\/strong><\/p>\n<\/td><\/tr>

\n

Used to store strings of fixed size<\/p>\n<\/td>

\n

Used to store strings of variable length<\/p>\n<\/td><\/tr>

\n

Can range in size from 1 to 8000 bytes<\/p>\n<\/td>

\n

Can range in size from 1 to 8000 bytes<\/p>\n<\/td><\/tr>

\n

Uses a fixed amount of storage, based on the size of the column<\/p>\n<\/td>

\n

Use varying amounts of storage space based on the size of the string stored.<\/p>\n<\/td><\/tr>

\n

Takes up 1 to 4 byte for each character, based on collation setting<\/p>\n<\/td>

\n

Takes up 1 to 4 byte for each character based on collation and requires one or more bytes to store the length of the data<\/p>\n<\/td><\/tr>

\n

Better performance<\/p>\n<\/td>

\n

Slightly poorer performance because length has to be accounted for.<\/p>\n<\/td><\/tr>

\n

Pads spaces to the right when storing strings less than the fixed size length<\/p>\n<\/td>

\n

No padding necessary because it is variable in size<\/p>\n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What does the \u201cN\u201d mean in CHAR(N) or VARCHAR(N)<\/h2>\n\n\n\n

The \u201cN\u201d does not mean the maximum number of characters that can be stored in a CHAR<\/code> or VARCHAR<\/code> column but instead means the maximum number of bytes a data type will take up. SQL Server has different collations for storing characters. Some character sets, like Latin,<\/em> store each character in one byte of space. In contrast, other character sets, like the one for Japanese, require multiple bytes to store a character.<\/p>\n\n\n\n

CHAR<\/code> and VARCHAR<\/code> columns can store up to 8000 bytes. If a single-byte character set is used, up to 8000 characters can be stored in a CHAR<\/code> or VARCHAR<\/code> column. If a multi-byte collation is used, the maximum number of characters that a VARCHAR<\/code> or CHAR<\/code> can store will be less than 8000. A discussion on collation is outside the scope of this article, but if you want to find out more about single and multi-byte character sets, then check out this<\/a> documentation.<\/p>\n\n\n\n

Truncation error<\/h2>\n\n\n\n

When a column is defined as a CHAR(N)<\/code> or VARCHAR(N)<\/code>, the \u201cN\u201d represents the number of bytes that can be stored in the column. When populating a CHAR(N)<\/code> or VARCHAR(N)<\/code> column with a character string, a truncation error like shown in Figure 1 might occur.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Figure 1: Truncation error<\/strong><\/p>\n\n\n\n

This error occurs when trying to store a string longer than the maximum length of a CHAR<\/code> or VARCHAR<\/code> column. When a truncation error like this occurs, the TSQL code terminates, and any following code will not be executed. This can be demonstrated using the code in Listing 1.<\/p>\n\n\n\n

Listing 1: Code to produce truncation error<\/strong><\/p>\n\n\n\n

USE tempdb;\nGO\nCREATE TABLE MyTable (A VARCHAR(10));\nINSERT INTO MyTable VALUES ('This String');\n-- Continue on \nSELECT COUNT(*) FROM MyTable;\nGO<\/pre>\n\n\n\n
The code in Listing 1 produced the error in Figure 1 when the INSERT<\/code> statement is executed. The SELECT<\/code> statement following the INSERT<\/code> statement was not executed because of the truncation error. The truncation error and script termination might be exactly the functionality you might want, but there are times when you might not want a truncation error to terminate your code.<\/p>\n\n\n\n
Suppose there is a need to migrate data from an old system to a new system. In the old system, there is a table MyOldData that contains data created using the script in Listing 2.<\/p>\n\n\n\n
Listing 2: Table in old system<\/strong><\/p>\n\n\n\n
USE tempdb;\nGO\nCREATE TABLE MyOldData (Name VARCHAR(20), ItemDesc VARCHAR(45));\nINSERT INTO MyOldData \nVALUES ('Widget', 'This item does everything you would ever want'), \n       ('Thing A Ma Jig', 'A thing that dances the jig');\nGO<\/pre>\n\n\n\n
The plan is to migrate the data in MyOldData<\/em> table to a table named MyNewTable,<\/em> which has a smaller size for the ItemDesc<\/code> column. The code in Listing 3 is used to create this new table and migrate the data.<\/p>\n\n\n\n
Listing 3: Migrating data to a new table<\/strong><\/p>\n\n\n\n
USE tempdb;\nGO \nCREATE TABLE MyNewData (Name VARCHAR(20), ItemDesc VARCHAR(40));\nINSERT INTO MyNewData SELECT * FROM MyOldData;\nSELECT * FROM MyNewData;\nGO<\/pre>\n\n\n\n
When the code in Listing 3 is run, you get a truncation error similar to the error in Figure 1, and no data is migrated.<\/p>\n\n\n\n
In order to successfully migrate the data, you need to determine how to deal with the data truncation to make sure all rows migrate across. One method is to truncate the item description using the SUBSTRING<\/code> function by running the code in Listing 4.<\/p>\n\n\n\n
Listing 4: Eliminating truncation error with SUBSTRING<\/strong><\/p>\n\n\n\n
DROP Table MyNewData\nGO\nUSE tempdb;\nGO \nCREATE TABLE MyNewData (Name VARCHAR(20), ItemDesc VARCHAR(40));\nINSERT INTO MyNewData SELECT Name, substring(ItemDesc,1,40) \nFROM MyOldData;\nSELECT * FROM MyNewData;\nGO<\/pre>\n\n\n\n
When running the code in Listing 4, all records are migrated. Those with an ItemDesc<\/code> longer than 40 will be truncated using the SUBSTRING<\/code> function, but there is another way.<\/p>\n\n\n\n
If you want to avoid the truncation error without writing special code to truncate columns that are too long, you can set the ANSI_WARNINGS<\/code> setting to off, as done in Listing 5.<\/p>\n\n\n\n
Listing 5: Eliminating truncation error by setting ANSI_WARNINGS to off.<\/strong><\/p>\n\n\n\n
DROP Table MyNewData\nGO\nUSE tempdb;\nGO \nCREATE TABLE MyNewData (Name VARCHAR(20), ItemDesc VARCHAR(40));\nSET ANSI_WARNINGS OFF;\nINSERT INTO MyNewData SELECT * FROM MyOldData;\nSET ANSI_WARNINGS ON;\nSELECT * FROM MyNewData;\nGO<\/pre>\n\n\n\n
By setting the ANSI_WARNINGS<\/code> off, the SQL Server engine does not follow the ISO standard for some error conditions, one of those being the truncation error condition. When this setting is turned off, SQL Server automatically truncates the source column to fit in target columns without producing an error. Care should be used when turning off ANSI_WARNINGS<\/code> because other errors might also go unnoticed. Therefore, changing the ANSI_WARNING<\/code> setting should be used cautiously.<\/p>\n\n\n\n
VARCHAR(MAX)<\/h2>\n\n\n\n
The VARCHAR(MAX)<\/code> data type is similar to the VARCHAR<\/code> data type in that it supports variable-length character data. VARCHAR(MAX)<\/code> is different from VARCHAR<\/code> because it supports character strings up to 2 GB (2,147,483,647 bytes) in length. You should consider using VARCHAR(MAX)<\/code> only when each string stored in this data type varies considerably in length, and a value might exceed 8000 bytes in size.<\/p>\n\n\n\n
You might be asking yourself, why not use VARCHAR(MAX)<\/code> all the time, instead of using VARCHAR<\/code>? You could, but here are a few reasons why you might not want to do that:<\/p>\n\n\n\n
VARCHAR(MAX)<\/code> columns cannot be included as a key column of an index.<\/p>\n\n\n\n
VARCHAR(MAX)<\/code> columns do not allow you to restrict the length of the column.<\/p>\n\n\n\n
In order to store large strings, VARCHAR(MAX)<\/code> columns use LOB_DATA allocation units for large strings. LOB_DATA<\/code> storage is much slower than using IN_ROW_DATA<\/code> storage allocation units.<\/p>\n\n\n\n
LOB_DATA<\/code> storage doesn\u2019t support page and row compression.<\/p>\n\n\n\n
You might be thinking VARCHAR(MAX)<\/code> columns will eliminate the truncation error that we saw earlier. That is partially true, provided you don\u2019t try to store a string value longer than 2,147,483,647 bytes. If you do try to store a string that is longer than to 2,147,483,647 bytes in size, you will get the error shown in Figure 2.<\/p>\n\n\n\n
\n
<\/figure>
<\/p>\n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Figure 2: Error when a string is longer than 2 GB in size<\/strong><\/p>\n\n\n\n
You should only use VARCHAR(MAX)<\/code> columns when you know some of the data you are going to store exceed the 8000-byte limit of a VARCHAR(N)<\/code> column, and all of the data is shorter than the 2 GB limit for the VARCHAR(MAX)<\/code> column.<\/p>\n\n\n\n
Concatenation problems with CHAR Columns<\/h2>\n\n\n\n
When a CHAR<\/code> column is not fully populated with a string of characters, the extra unused characters are padded with spaces. When a CHAR<\/code> column is padding with spaces, it might cause some problems when concatenating CHAR<\/code> columns together. To better understand this, here are a few examples that use the table created in Listing 6.<\/p>\n\n\n\n
Listing 6: Sample Table<\/strong><\/p>\n\n\n\n
USE tempdb;\nGO\nCREATE TABLE Sample (\nID int identity,\nFirstNameChar CHAR(20),\nLastNameChar CHAR(20),\nFirstNameVarChar VARCHAR(20),\nLastNameVarChar VARCHAR(20));\nINSERT INTO Sample VALUES ('Greg', 'Larsen', 'Greg', 'Larsen');<\/pre>\n\n\n\n
The Sample<\/em> table created in Listing 6 contains 4 columns. The first two columns are defined as CHAR(20)<\/code> and the second two columns are defined as VARCHAR(20)<\/code> columns. These columns will be used to store my first and last name.<\/p>\n\n\n\n
In order to demonstrate the concatenation problem associated with padded CHAR<\/code> columns, run the code in Listing 7.<\/p>\n\n\n\n
Listing 7: Showing concatenation problem<\/strong><\/p>\n\n\n\n
SELECT FirstNameChar + LastNameChar AS FullNameChar, \n       FirstNameVarChar + LastNameVarChar AS FullNameVarChar FROM Sample;<\/pre>\n\n\n\n
Report 1 contains the output when Listing 7 is executed<\/p>\n\n\n\n
Report 1: Output when code in Listing 7 is run<\/strong><\/p>\n\n\n\n
\"Image<\/figure>\n\n\n\n
<\/p>\n\n\n\n
In Report 1, the FirstNameCHAR<\/code> column contains several spaces between my first and last name. These spaces came from the spaces that were padded onto the FirstNameCHAR<\/code> column when it was stored in the CHAR<\/code> column. The FullNameVARCHAR<\/code> column does not contain any spaces between first and last name. No spaces are padded when column values are less than the length of the VARCHAR<\/code> column.<\/p>\n\n\n\n
When concatenating CHAR<\/code> columns, you might need to remove the trailing spaces to get the results you want. One method of eliminating the spaces can be done using the RTRIM<\/code> function, as shown in Listing 8.<\/p>\n\n\n\n
Listing 8: Removing trailing spaces using the RTRIM function<\/strong><\/p>\n\n\n\n
SELECT RTRIM(FirstNameChar) + RTRIM(LastNameChar) AS FullNameChar, \n       FirstNameVarChar + LastNameVarChar AS FullNameVarchar \nFROM Sample;<\/pre>\n\n\n\n
Output in Report 2 created when Listing 8 is executed is shown below.<\/p>\n\n\n\n
Report 2: Output when Listing 8 is run<\/strong><\/p>\n\n\n\n
\"Image<\/figure>\n\n\n\n
<\/p>\n\n\n\n
By using the RTRIM<\/code> function, all the additional spaces added to the FirstNameCHAR<\/code> and the LastNameCHAR<\/code> columns were removed before the concatenation operations were performed.<\/p>\n\n\n\n
Problems searching CHAR columns for spaces<\/h2>\n\n\n\n
Because CHAR<\/code> columns might be padded with spaces, searching for a space might be problematic.<\/p>\n\n\n\n
Suppose you have a table containing phrases, like the one created in Listing 9.<\/p>\n\n\n\n
Listing 9: Creating Phrase <\/em>table<\/strong><\/p>\n\n\n\n
USE tempdb;\nGO\nCREATE TABLE Phrase (PhraseChar CHAR(100));\nINSERT INTO Phrase VALUES ('Worry Less'),\n                          ('Oops'),\n                          ('Think Twice'),\n                          ('Smile');<\/pre>\n\n\n\n
Some phrases in table Phrase <\/em>consist of just a single word, while the rest have two words. To search the Phrase <\/em>table to find all the phrases that contain two words, the code in Listing 10 is used.<\/p>\n\n\n\n
Listing 10: Trying to find two-word phrases<\/strong><\/p>\n\n\n\n
SELECT PhraseChar FROM Phrase WHERE PhraseChar like '% %';<\/pre>\n\n\n\n
The output in Report 3 is produced when Listing 10 is run.<\/p>\n\n\n\n
Report 3: Output when Listing 10 is executed<\/strong><\/p>\n\n\n\n
\"Text\n\nDescription<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Why did all the phrases in the Phrase <\/em>table get returned when only two rows contained 2-word phrases? The search string % %<\/code> also found the spaces that were padded to the end of the column values. Once again, the RTRIM<\/code> can be used to make sure the spaces associated with the padding are not included in the search results by running the code in Listing 11.<\/p>\n\n\n\n
Listing 11: Removing the trailing spaces<\/strong><\/p>\n\n\n\n
SELECT PhraseChar FROM Phrase\nWHERE RTRIM(PhraseChar) like '% %';<\/pre>\n\n\n\n
I\u2019ll leave it up to you to run the code in Listing 11 to verify if it only finds two-word phrases.<\/p>\n\n\n\n
Performance consideration between VARCHAR and CHAR<\/h2>\n\n\n\n
The amount of work the database engine has to perform to store and retrieve VARCHAR<\/code> columns is more than it takes for a CHAR<\/code> column. Every time a VARCHAR<\/code> column is retrieved, the Database engine has to use the length information stored with the data to retrieve a VARCHAR column value. Using this length information takes extra CPU cycles. Whereas a CHAR<\/code> column and its fixed length allow SQL Server to more easily chunk through CHAR<\/code> column based on their fixed-length column definitions.<\/p>\n\n\n\n
Disk space is also an issue to consider when dealing with CHAR<\/code> and VARCHAR<\/code> columns. Because CHAR<\/code> columns are fixed-length, they will always take up the same amount of disk space. VARCHAR<\/code> columns vary in size, so the amount of space needed is based on the size of the strings being storeded instead of the size of the column definition. When a large majority of the values stored in a CHAR<\/code> column are less than the defined size, then possibly using a VARCHAR<\/code> column might actually use less disk space. When less disk space is used, less I\/O needs to retrieve and store the column value, which means better performance. For these two reasons, choose between CHAR<\/code> and VARCHAR<\/code> wisely based on the varying size of the string values being stored.<\/p>\n\n\n\n
Read also:<\/strong> In-memory optimized tables in SQL Server<\/a><\/p>\n\n\n\n
CHAR, VARCHAR, and VARCHAR(MAX)<\/h2>\n\n\n\n
CHAR columns are fixed in size, while VARCHAR<\/code> and VARCHAR(MAX)<\/code> columns support variable-length data. CHAR columns should be used for columns that vary little in length. String values that vary significantly in length and are no longer than 8,000 bytes should be stored in a VARCHAR<\/code> column. If you have huge strings (over 8,000 bytes), then VARCHAR(MAX)<\/code> should be used. In order to store VARCHAR<\/code> columns, the length information along with the data is stored. Calculating and storing the length value for a VARCHAR<\/code> column means SQL Server has to do a little more work to store and retrieve VARCHAR<\/code> columns over CHAR<\/code> column data types.<\/p>\n\n\n\n
The next time you need to decide if a new column should be a CHAR<\/code>, VARCHAR<\/code>, or VARCHAR(MAX) <\/code>column, ask yourself a few questions to determine the appropriate data type. Are all the string values to be stored close to the same size? If the answer is yes, then you should use a CHAR<\/code>. If strings to be stored vary greatly in size, and values are all less than or equal to 8,000 bytes in size, then use VARCHAR<\/code>. Otherwise, VARCHAR(MAX) <\/code>should be used.<\/p>\n\n\n\n
If you liked this article, you might also like <\/em>SQL Server identity column.<\/em><\/a><\/p>\n\n\n\n
\n    
\n        
\n            
\n                
Fast, reliable and consistent SQL Server development…<\/h3>\n                
\n                                            …with SQL Toolbelt Essentials. 10 ingeniously simple tools for accelerating development, reducing risk, and standardizing workflows.                                    <\/div>\n            <\/div>\n                            Learn more & try for free<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
\n    
FAQs: When to use CHAR, VARCHAR or VARCHAR(MAX) in SQL Server<\/h2>\n\n                        
1. What is the maximum length of VARCHAR and VARCHAR(MAX) in SQL Server?<\/h3>\n            
\n                
VARCHAR can store up to 8,000 bytes (characters for single-byte encodings). VARCHAR(MAX) can store up to 2^31 – 1 bytes (approximately 2 GB). For VARCHAR(MAX), values under 8,000 bytes are stored in-row by default; larger values are stored as LOB (Large Object) data with a pointer in the row, which has different performance characteristics for sorting and indexing.<\/p>\n            <\/div>\n                    
2. What is the difference between CHAR and VARCHAR in SQL Server?<\/h3>\n            
\n                
CHAR is a fixed-length data type that always uses the defined number of bytes, padding shorter values with trailing spaces. VARCHAR is variable-length and only uses the storage needed for the actual data plus 2 bytes of length overhead. CHAR is more efficient for columns where all values are the same length; VARCHAR is better when lengths vary, as it avoids wasting storage on padding.<\/p>\n            <\/div>\n                    
3. Does CHAR or VARCHAR perform better in SQL Server?<\/h3>\n            
\n                
For fixed-length data, CHAR can be marginally faster because SQL Server doesn\u2019t need to calculate variable lengths. For variable-length data, VARCHAR is better because it reduces I\/O by storing less data per row. In practice, the performance difference is usually negligible for most workloads – choose based on data characteristics rather than micro-optimization.<\/p>\n            <\/div>\n            <\/section>\n","protected":false},"excerpt":{"rendered":"
Compare CHAR, VARCHAR, and VARCHAR(MAX) in SQL Server – when to use each, storage differences, performance impact, and maximum length limits. Includes decision guide and examples.…<\/p>\n","protected":false},"author":78478,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[53,143525],"tags":[5134],"coauthors":[11330],"class_list":["post-93166","post","type-post","status-publish","format-standard","hentry","category-featured","category-learn","tag-sql-prompt"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/93166","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/78478"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=93166"}],"version-history":[{"count":6,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/93166\/revisions"}],"predecessor-version":[{"id":109049,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/93166\/revisions\/109049"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=93166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=93166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=93166"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=93166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}