HTML code in Scrivener Text

We write a web-site,, which is read in 100+ countries every month. The way I used I create my posts was to write them in Scrivener and then paste them via a Word style I/p box onto the web-site. I have changed from using Safari browser to using Firefox which doesn’t conflict with Typinator the spell checker I rely on. Sadly now the line spacing in the text is now all too close because, my developer tells me, the HTML is old and uses tags etc. that are no longer used, e.g. Scrivener uses HTML BIG for a line return when for a heading it should now use HT2. So my text appears to have no line breaks??

Apparently Firefox takes things literally, while Safari overcomes this.

I don’t want to go back to SAfari, is there any way of overcoming this problem.? Introducing the latest HTML code into the text?

Look forward to hearing from you. Thanks in anticipation and regards, Jack

Perhaps this is out of your safety zone, but why not use markdown for your writing in Scrivener, and then an app like Marked 2 can do a live conversion to HTML (it previews your text by converting it into HTML as you write). Or if you don’t want to buy Marked 2, just compile Multimarkdown to HTML directly?

Markdown was originally designed exactly for blog writing, it uses elegant and simple plain text formatting to generate clean and compliant modern HTML. Indeed some blog systems allow you to write directly in markdown, and the server itself does the conversion.


This is a major heading

This is text paragraph, with some emphasised text.

  1. A numbered list
  2. Blah

This is a quote from someone important

I don’t really know what your web developer is talking about here, none of that is HTML that I’m familiar with, old or new. But it doesn’t sound like you are using HTML at all with Scrivener, no? You mention copying and pasting text—I guess directly out of the text editor?—into some kind of Google Doc type thing in the website. So whatever HTML you get out of that has little or nothing to do with Scrivener. That’s a combination of the browser and the website doing the conversion.

That aside, the best approach I’ve seen for generating good quality HTML without hand-coding it is to use some kind of Markdown type of converter, which has the advantage of being something you can type nearly anywhere, and in Scrivener there is the advantage of it having native MultiMarkdown integration as one of its compile options. It can, among other things, generate headings based on your draft outline hierarchy. Working that one, one pastes in raw HTML rather than relying upon browsers and Javascript to convert from freeform RTF formatting. There is a chapter in the user manual on MultiMarkdown. Give the introduction a skim and see if that’ll be something you can work with. You won’t find clean output like that from any word processor based conversion (let alone pasting into a browser) that I am aware of.

P.S. I use Typinator as well, what should I look out for with Safari? I don’t use that browser often, only for a few things.


Typinator is core to how I work, but if you safari all the time, like I used to, it turns off (the black eyes face) as the password security feature kicks in after some or a little time. Gue the developer of Typinator blames Safari and 1Password for the auto turning off. My solution is to use a combination of Firefox and Typinator then no turning off.

Regards, Jack

Nontroppo and Amber,
I am not into HTML at all. Our site is written in ExpressionEngine (used in the Apple and BBC’s sites) who make it very easy to post all sorts of stuff. (BBC journalists are an impatient lot.) I used to:

  1. use Scrivener to develop and edit the articles, and then
  2. with Safari as the supporting browser to access the backend of our site (, to copy and paste from Scrivener into the Word input area. Which worked beautifully.
    But when I do the copy and pasting through the FireFox browser the spacing goes wonky because according to my developer the new paragraph HTML symbol used in Scrivener (I thought he said BIG and it should be HT2 ) is out of date and so Firefox, which is much more rigorous than Safari (in so many ways), doesn’t insert new paragraph.
    I don’t want or need to use Marked 2 or Multimark, I just want to be able to do simple writing and posting as my previous solution. If my developer is right (?) then all the Scrivener team in their version 3 is to insert the up-to-date HTML code automatically in basic text.
    (I’ve discovered that there is a solution to my problem: copy and paste from Scrivener to Word and then from Word to Firefox. I feel that is an unnecessary step just as using Market 2.)
    I’ve used and loved Scrivener for many years. Normally it makes my life and writing easier, but this time marginally not so. Regards, Jack

This may be coming round at this from the opposite direction, but I’ve used TypeIt4Me (rather than Typinator) for over 20 years and never come across these problems. (I also use 1Password). AFAIK TypeIt4Me will import your Typinator abbreviations file(s). Just a thought.

Ah, I know what you mean with Typinator. I’ve seen that quite a bit with 1Password as well. There isn’t much they can do about it I think, as it has to do with the other program not leaving password entry mode when it should.

Well to help you out with the other problem I would need quite a bit more detail in terms of what is happening and how. Maybe it would be easier if your web developer got in touch with us and provided a demo page with input/output so we could use the same technology you do and see test results with pasting.

What I can advise you try in the meantime is copy and paste some text from Scrivener into the free macOS TextEdit program, then copy and and paste from there and see if the result is any different. I’m guessing it won’t be, since that’s the same text editor component we use and very basic things like copy and paste are how the Mac works rather than how Scrivener works per se.

If TextEdit is the same, I think you will find using Safari for this one site is your best recourse. I have to use it for a few sites as well.

My guess would be that not much would change for them in this regard. TypeIt4Me, like all well-behaved (i.e. non-spyware key-logging stuff) software on a Mac is going to stop watching keyboard input when a secure event input is registered—which things like browsers and password managers will do when you start typing into an authentication field, or anything that might be considered sensitive information.

The problem is entirely out of the text expansion utility’s hands in that some programs do not cleanly stop the secure event mode and you end up getting locked out of your expansion software perpetually. I’ve even been locked out when the original software was shut down, all the way down to nothing left running but Finder—so I presume it is in part a macOS bug too.

It’s more likely you just don’t have the bug, and probably wouldn’t see it with Typinator either. I don’t have any problems with Safari for example—but I do in 1Password and one or two other programs.

Scrivener is NOT a HTML app. It does not use HTML to create or store its text. It does not copy HTML to the clipboard. It uses Rich text (RTF). The problem is more fundamental, that rich text is being converted outside of Scrivener, and this conversion is at fault. Microsoft Word supports rich text, but it itself now uses an XML document structure, with full styling support and so I suspect what Word copies to the clipboard is going to be much more useable. This is why Firefox treats Word data different to Scrivener data when it does its conversion.

Scrivener 3 will have style support, but this is built on top of RTF so unless the app that converts the clipboard data better (Safari, Firefox or a clipboard manager) then this is not going to solve your very specific use case.

Why not try Chrome or Opera and see if they handle the pasting better. Again, Scrivener cannot do anything here because it is not a HTML app, does not create HTML code (except on compile in specific formats often using external apps).

My guess would be:

  • Safari does a good job of supporting the core rich text that the macOS text engine saves to the pasteboard. After all that’s what Mail uses and countless third-party programs like Scrivener. Apple would want to support their own text system.
  • Firefox is a cross-platform program and the developers are likely going to be more interested in sorting out what 99.9% of their users are going to be pasting from, Word (and it wouldn’t surprise me if they support good pastes from Libre/OpenOffice). They wouldn’t be motivated to spend a lot of time tuning input from a text engine that, statistically speaking, few people use.

To me there are (atleast) three parts to this issue:

  1. What is going on the clipboard when you Copy? Applications decide what goes on the clipboard when you cooy from the app and can put multiple things on the cliobiard of differing type. For example, a text app might put a plain text version of some selected text on the clipboard and also put a rich text version of it and also put an html version of the text on the clipboard.

  2. What is being pulled from the clipboard when you Paste? Applications decide what sort of data to look for on the clipboard and if multiple kinds of data work it will have a preference order of which to pull when more than one of them is available.

  3. What is the receiving website doing with the pasted data? My understanding is that the OP is pasting into a field on a webpage. So, there also is a question of what the webpage is coded to do upon paste into that field. I know of one (infuriating) case of a content management system which seemed to be processing on paste immediately. You would get the impression that what you saw in the field was what was on your clipboard, but not so! The textual data had already been processed and re-presented. (This was in a Blackboard-type CMS. In this case, for example, the website was replacing tab characters with formatting. In their not-so-infinite wisdom, the programmers assumed that the raw character data of student submissions was not important, but only its “look” in the browser. Quite wrong for my own use-case, so that is how all this came to light. In that case, too, results varied with different browsers.)

The question here is what unholy mix of these three things is getting in the way of things working as expected.


The way TypeIt4Me works (sorry to labour the point!) is to store the clipboard contents in its buffer and then use/release the clipboard after each expansion. If in the meantime you copy something else to the clipboard, then what’s in the buffer simply changes to reflect that, so that ordinary copy/paste works as normal, as expected.

I actually use a Clipboard manager and exclude it as an application from TypeIt4Me so that the latter’s expansions don’t constantly appear in iClip.

Finder > Edit > Show Clipboard shows the default content type (RTF from Scrivener), but Apple also have a cool little sample app that inspects all content types in the macOS clipboard: … Intro.html

I found a older (2009) compiled version here (if anyone with XCode could compile the updated version that would be great!!!): … d-hex-form

This shows Scrivener copies RTF and plain text in several forms (absolutely no HTML data of any type):

So the difference between Safari and Firefox most likely occurs on your point (2). How to debug that I have no idea. And yes, many text editing components in CRMs are an ugly mess.

Lovely! Thanks. I was looking all over for that utility yesterday. I’ve attached a build of it. (60.6 KB)

I’m wondering if he’s maybe using one of the Copy Special | Copy as HTML options.

Screen Shot 2017-08-18 at 10.49.20 AM.png

If so that might be throwing a wrench into the works as those three seem to result in quite different code.

Related question - will the tag nesting when using Copy Special | Copy as BBCode be fixed in Scriv 3? Currently it does things like this:

[b][i]Bold Italic[/b][/i]

Which trips up some message boards. Not a huge deal by any means, but might be nice to have fixed.

Alas, BBCode copy won’t be a thing in 3.0.

Ah well. It crossed my mind once or twice, but I don’t think I ever did end up using that feature so no big loss (for me at least).