Javascript - Degree Symbol

Placing the Degree Symbol (°) on a canvas is a recurring problem - sometimes it works, and sometimes it doesn't. These pages explain why and present a procedure that fixes it.

In all cases, text is placed on a canvas using javascript code similar to the following.

If you look at this html file in notepad (or in the browser's debug window), you will notice that the Degree Symbol is rendered the same there as it is above - this is what I expect. (The Degree Symbol in the first paragraph at the top of this page was entered in this html file as °.)

Unfortunately, in some cases (details below) the Degree Symbol is shown on a canvas as a black diamond with a question mark ! :(

After significant research, I think I understand (most of) what is happening. Basically, the Degree Symbol is encoded differently, and interpreted differently, depending on whether a text file is stored as (encoded as) ANSI or UTF-8. For most browsers (that I've tested)

So, basically, the rule is - Javascript files that contain the Degree Symbol should always be encoded as UTF-8.

These are the testcases - UTF8 ANSI ANSI with Chrome Failure ANSI with meta tag - each one is configured to test a specific combination of parameters.

While developing these pages, I stumbled on to (and documented) several browser design problems.

Controlling the encoding | Other file issues | Meta tag | Testcase Description - Results Chrome 63 - Local vs Web
How I found this problem | Ways to represent the Degree Symbol - Additional codes | Unicode Warning | Old Notes

Controlling the encoding

Text files can be saved with either ANSI encoding or UTF-8 (unicode) encoding. On Windows XP, when Windows Explorer creates a new text file (right click in a directory and select New / Text Document), ANSI encoding is the default. For both notepad and wordpad, to change it, use File / SaveAs... and select the encoding you want. Once an encoding is selected, additional saves (File / Save or alt fs) will not change it.

I was able to verify that the Chrome 49 SaveAs... produces a UTF-8 file. However, I could only get that option via Inspect / Paused / Sources (where only javascript files can be edited, it was not available via Inspect / Elements where the main html file can be edited).

Warning: If the main html file is encoded as Unicode, then javascript files encoded as ANSI (8 bits per character) may be automatically assumed to be Unicode (UTF-16 - 16 bits per character) and, as a result, will not be processed. Using the Chrome 49 debug window, the file was read, but the characters were nonsense. On Windows 10, Chrome and Firefox had similar issues, however, MS Edge and IE correctly interpreted the javascript file.

To quote from w3schools

I disagree with the final part about "solving problems". Unicode causes all kinds of problems - it makes files larger, causes interoperability problems, makes perfectly good software obsolete, and much more. From my point of view - unicode is a virus that keeps on giving.

For example, I took one of my test files, copied it, and saved the copy using each of the encoding types - the sizes in the table below are in actual bytes.

So yes, unicode doubles the file size, slows down all data transfers, and makes text files hard to read with the debug tools I use all the time.

Combine that with the warning above, and the fact that this page is necessary, and you get an idea of why I don't like unicode. There is more, but that is not the purpose of this page.

Other file issues

I tried creating UTF-8 encoded text files using notepad - what a disaster.

This was pretty frustrating. The problem was that the UTF-8 text file starts with 3 "binary" (not visible in notepad) characters that define the type of encoding and only had a few additional (normal) characters in it. When I added more characters - the "problem" went away. Specifically.

I never expected that the number of characters would control whether examdiff classifies a UTF-8 file as binary or text. With ANSI files, there is no confusion.

While the fix was extremely simple, I lost a lot of time trying to figure out why notepad was creating binary files! when the real problem (I think) was that examdiff was attempting to verify that the file was not binary - and that test was failing.

With wordpad, examdiff reported that any file saved as Unicode Text Document is also binary. Just a guess - it is saved as UTF-16 - but I have no way to verify that. At any rate, and because of this, I only use notepad to intentionally produce unicode files.

Meta tag

Besides saving a file with a specific encoding, it is possible to specify the encoding via a meta tag. Presumably, this is provided because some servers were not including the necessary 3 characters that provide that information.

At any rate, when I made a local copy of an application which displayed Degree Symbols, Chrome not only saved the html text as UTF-8, but it also automatically added that tag.

Of course, when that tag is present and the html file is actually encoded as ANSI, there are problems!!!

As shown on the separate test page, the Local HTML and ANSI js canvases fail with the black diamond .. as do all the Degree Symbols present in the html text. Only the symbols entered as ° and those placed on a canvas via a javascript file saved with UTF-8 encoding (UTF-8 js) are rendered as expected

At some point (several years ago) I removed this tag from the file while troubleshooting basically the same Degree Symbol problem. Since Chrome obviously added it, and since I had no idea why, I simply deleted it (actually, commented it out). Since the page still displayed the same as before, I figured that it had no purpose and left it that way. During research for this page, I re-enabled it and discovered this issue.

Notice that this failure, and the Chrome 63 only issue (testcase) show black diamonds in exactly the same locations - except that this error occurs in all (tested) browsers .. not just Chrome 63.

The ANSI js canvas error always occurs when the test page is loaded from the local file server .. but sometimes works (shows the Degree Symbol) when loaded from a remote web server. I inspected the HTTP headers, but can not determine why this happens.

Testcase Description

As you know, both html and javascript are stored in text files. As mentioned above, there are 2 different ways for a text file to store the c Both of these will display exactly the same in notepad, but differently when writing on an HTML5 canvas using javascript (and that may be browser dependent).

(For some applications, either (or both) the html and javascript may be generated by a program on the server. The problems described on this page still apply, but I have made no effort to test those scenarios.)

In order to demonstrate this issue, I have provided 4 additional html pages and 2 javascript files.

There are a number of additional testcases (scenarios) that could be (and, perhaps, should be) tested, but these are enough (for now) to suggest a fix for any additional failures that might be encountered.

Those four testcases were run on 5 browsers.

There were a number of very strange, browser specific issues - they are discussed in detail on a separate page (or use the links in the table).


These are screen captures of the various testcases - when testing from a file server, only 3 are necessary since 2 of them are identical. However, when testing via the web, a few of the results are different (and not consistent!).

Based on those results

This probably explains why my working application (back in 2015) suddenly stopped working and I could not figure out what happened - since the main html file was always saved as UTF-8, I probably refactored some javascript code from the main html file into a separate file saved with ANSI encoding.

Chrome 63 - Local vs Web

Since an internet connection is not always available, I always develop, and frequently use, my applications directly off a local file store (hard drive). When at meetings, I use a laptop. As a result, these pages, and their results, were developed using files on a local disk drive.

I was totally surprised to see different results after uploading these pages to a server - errors and results that I spent several days trying to characterize were no longer the same. New browser differences appeared. Many of these are intermittent - they fail the first time, and then magically go away.

It gets worse - When switching between testcases on the server, sometimes there will be an error. Refresh (F5) has no effect, but ctrl-F5 reloads the same javascript files (no change in files) and the display will change. It appears that the server is screwing with the file formatting! However, Chrome 63 is the only browser (of the 5 I tested) that has this problem.

In general, I can force some issues to go away by pressing ctrl-F5 to reload the javascript files. However, requiring users to perform this "extra" task is never acceptable.

To recreate the first two issues, first run UTF-8 encoded file and press ctrl-F5 to get the browser in a mode to fail.

UTF8 with hex codes also has intermittent results - the second Degree Symbol on the ANSI canvas fails in all browsers, but with Chrome 63, ctrl-F5 fixes it.

Regardless of the results, because I need all my apps to run both locally and via the web, I must follow the most restrictive rules. Since the UTF-8 encoded javascript files appear to always work as expected, that remains my suggested way to avoid these problems.

(Intermittent software - give me a break!)

How I found this problem

This is the sort of problem that just suddenly happens - one minute you have a fully functional application, and the next, nothing works. In this case, I was using examdiff to compare javascript files. (I do this occasionally to find differences between what I am working on and some previous version of the same file.) During the compare, I noticed that there were 3 extra letters at the beginning of the files - and that they were not visible when using notepad. (In the following example, the second character is a space which is not present in a UTF-8 encoded file. It was added here because, without it, Chrome 63 makes the characters invisible and then interprets this page in the wrong way!) Not realizing what these were, or why they were important, I attempted to get rid of them. (My general - and now obviously incorrect - policy was to get rid of anything you can't see.) Saving the file with wordpad worked - the 3 invisible characters at beginning of file were removed :) Success .. or so I thought. Unfortunately, after that the Degree Symbol incorrectly rendered on a canvas as a black diamond with a question mark.
As a result, I had to figure out what those symbols meant and determine how to get them back. Since none of this was obvious, and since this was a repeat of a problem I had 3 years ago, I decided to document what I learned here.

Ways to represent the Degree Symbol

Since the old (MSDOS) days, the Degree Symbol was part of the extended ASCII character set - the characters with decimal values greater than 127.

Standard representations of the Degree Symbol

There are several ways to enter this into an html file

Just to be different, in wordpad the Degree Symbol can be entered via the number pad using either numeric code - 248 or 176!! Using notepad, 176 produces a black bar and a unicode warning when the file is saved. (More details below)

In a javascript file, you can

However, you can not use the html Entity - ° (°) - It works in html text, but not when writing on a canvas using javascript.

If you prefer to use a hex string in a javascript string, replace the "°" with "\xB0"

Using decimal and/or hexadecimal numbers is suggested on a number of web sites and it works in ANSI encoded javascript files when the main html file is stored as UTF-8. (I verified this in all 5 browsers.) However, I prefer not to use it because In my opinion, the fact that the hex code is interpreted differently from a character with the same hex code (verified using a hex editor) indicates a design problem. The fact that all 5 browsers have the exact same response indicates (to me) that this is by design.

ANSI with hex codes and UTF8 with hex codes use modified versions of the javascript to demonstrate the hex codes on all 3 canvases. They are not included with the other testcases because this is not my suggested solution. YMMV

When run locally with Chrome 63, ANSI with hex codes shows Degree Symbols in all test locations. However, when run via the web, the Degree Symbol typed directly into the ANSI javascript file shows on the canvas and in the debug inspector as a black diamond!!!

Additional codes

For completeness, HTML5 supports special codes for °F and °C, but whether or not they are supported is browser dependent (ie, don't use these).

Unicode Warning

As mentioned above, the extended ASCII codes can be entered via the number pad. Since one of them (the Degree Symbol) is ok in an ANSI encoded file, I assumed (incorrectly) that they all are.

When I entered the Degree Symbol into notepad via the number pad alt + 248 and attempted to save the file (using alt fs) - no problem.

However, I originally tried alt + 176 (the decimal ANSI value). In this case, alt fs produced the following message (same in XP and 10 - with the long path and filename removed).

Clicking Cancel opens the Save As dialog box (which has the necessary options).

To be clear, I discovered the ANSI and UTF-8 options only because I mistakenly tried the wrong keyboard value and saw that message. Previously, I had no clue. These can be accessed any time via the File / SaveAs... dialog under Encoding and I used them repeatedly while trying to understand this problem.

As mentioned above, wordpad has a similar option for ANSI (Text Document), but no option for UTF-8. Just to be different, the Degree Symbol can be entered using either numeric code - 248 or 176!! When entering other, random, codes, it does not produce a warning message.

Old Notes

From my notes about 3 years ago Of course, writing this page in 2018, I don't remember any of that - just that it was quite difficult to fix the problem.

At any rate, for that application, the current version (and all the archive versions) of the main html file are saved as UTF-8 and that is where many of the Degree Symbols are. Apparently (based on file dates), I refactored code from an ANSI javascript file to the UTF-8 html file and that fixed the problem - but without me understanding why.

At some point, based that note and the current file types, I presume that I used Chrome to pasted the Degree Symbol into an existing ANSI javascript file and, when I saved it, Chrome converted it to UTF-8. Later code files worked because they where made by simply copying existing (working) files.


When visiting the original application page and inspecting the Response Headers via the Chrome debugger, these are displayed.

When this original program is saved via Chrome (I did it again today), there are 2 files - one html and one javascript. Both files are saved with unix line endings, the html file was saved with UTF-8 encoding, the javascript file with ANSI encoding. Chrome also replaced the original html header

with the following (in both grey boxes, returns were added to improve readability) A search of my archive shows that the meta tag was still enabled for version 0.02, and commented out for version 0.03. My notes do not say why I made that change.

However, this means that the Degree Symbol problem was "fixed" (hacked) before I removed the tag in the next version.

Typically, I use wordpad to remove the unix line endings - in this test of the html file, it did and it saved the file keeping the UTF-8 encoding. This is interesting since the "problem" this page is about was caused by wordpad saving a file with UTF-8 encoding as an ANSI encoded file. I don't remember (since it was several days ago), but I probably selected either Text Document or Text Document - MS-DOS Format on the SaveAs.. dialog - which I have verified both convert the file encoding from UTF-8 to ANSI which is what I was originally (and cluelessly) trying to do.

Author: Robert Clemenzi
URL: http:// / Languages / Javascript / Degree_Symbol / Degree_Symbol.html