HTML4 / XHTML1 allows only GET and POST in forms, now it seems like HTML5 will do the same. There is a proposal to add these two but it doesn't seem to be gaining traction.

What were the technical or political reasons for not including PUT and DELETE in HTML5 specification draft?

  • 7
    HTML is the markup language, HTTP is the protocol Commented Oct 13, 2011 at 13:57
  • 62
    @ratchet freak: I am aware of that. Nevertheless I'm asking specifically about HTML as it defines only GET and POST as allowed <form> methods.
    – FilipK
    Commented Oct 13, 2011 at 14:01
  • A typical scenario is a form with tabular data, where user need to PUT more lines or not, as "more lines" are user decision. Using Javascript+POST is artificial, perhaps HTML6 will show an alternative FORM feature to do this kind of operation. Commented Oct 27, 2014 at 13:43
  • 1
    I answered this question when someone else asked it on Stack Overflow, and feel my contribution there has something to add to the excellent responses above, for anyone reading this far down the page :o) Why don't browsers support PUT and DELETE requests and when will they? Commented Jan 27, 2016 at 17:47
  • 5
    is this still valid? w3.org/TR/form-http-extensions/#http-delete-form Commented Apr 23, 2016 at 4:12

7 Answers 7


This is a fascinating question. The other answers here are all speculative, and in some cases flat-out incorrect. Instead of writing my opinion here, I actually did some research and found original sources that discuss why delete and put are not part of the HTML5 form standard.

As it turns out, these methods were included in several, early HTML5 drafts (!), but were later removed in the subsequent drafts. Mozilla had actually implemented this in a Firefox beta, too.

What was the rationale for removing these methods from the draft? The W3C discussed this topic in bug report 10671. Mike Amundsen argued in favor of this support:

Executing PUT and DELETE to modify resources on the origin server is straight-forward for modern Web browsers using the XmlHttpRequest object. For unscripted browser interactions this not so simple. [...]

This pattern is required so often that several commonly-used Web frameworks/libraries have created a "built-in" work-around. [...]

Other considerations:

  • Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable, PUT responses are not(6), DELETE responses are not(7))
  • Using a non-idempotent method (POST) to perform an idempotent operation (PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to repeat this action?").
  • [...]

It's worth reading his entire post.

Tom Wardrop also makes an interesting point (href):

HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? [...]

It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests.

The bug was eventually closed as Won't Fix by Ian Hickson, with the following rationale (href):

PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.

However, that's not the end of the story! The issue was closed in the W3C bug tracker and escalated to the HTML Working Group issue tracker:


At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it.

  • 105
    +1 for putting the research effort in place and digging up a number of external references to properly answer the question.
    – user53019
    Commented Sep 17, 2013 at 19:53
  • 8
    @shivakumar I think what you're really asking is why bother with HTML when JavaScript can already do the job? That's a fair question. I guess the OP's question comes more from a place of curiosity than of practicality. HTML and HTTP are two standards made for each other, and yet HTML seems to be unaware of some of HTTPs most basic properties. "Why?" is a natural question to ask. Commented Aug 28, 2014 at 17:21
  • 39
    Surely you have to include a payload for PUT and for DELETE it is possible? Also if "doesn't make much sense with forms" then why are people asking for it and why does a lot if software he workarounds built in. Odd how one person can just decide what the rest of world needs or wants...
    – Jonathan.
    Commented Sep 2, 2014 at 10:30
  • 6
    @Ajedi32 I e-mailed Cameron Jones (the editor of the current draft) and asked him about the status. He wrote, "the spec is still alive and progressing through the W3C process - it's currently in working draft and the next stage is to hopefully move it into Candidate Recommendation (CR)." He also wrote, "The main factor in this is community interest… If you and others have interest in seeing this implemented i would definitely recommend advocating for such through public-html-comments, the whatwg or the vendors own mailing lists." Commented Feb 4, 2015 at 17:43
  • 7
    @Ajedi32 here's the post: lists.w3.org/Archives/Public/public-html/2015Feb/0000.html I encourage everybody who's interested to reply to this post on the public-html mailing list. Commented Feb 6, 2015 at 14:11

This is was raised in 2010 as Bug 10671 consider adding support for PUT and DELETE as form methods.

There was a moderate amount of pushback for this "feature" and some heavy-handedness but eventually this was escalated as two issues on the Working Groups bug tracker:

The issue ISSUE-196 resulted in a concensus decision to perform no change to the specification as the HTML specification does not currently restrict how responses to POST requests are handled. I believe this particular issue was raised in attempting to reconcile POST redirect patterns commonly in use and how ReSTful servers often provide 2xx responses with short messages rather than something useful to be rendered in a browser.

The issue ISSUE-195 was presented to the chairs. Cameron Jones stepped up to volunteer in writing a change proposal on the 18th of January 2012 which he submitted to become the first working draft on the 29th May 2014. The draft will go through the W3C recommendations process.

With any luck, this will soon become a W3C recommendation and implemented by browser vendors, and would be a great forward step in removing the blockers to produce unified, semantic and browser friendly ReSTful services. I imagine this will spark an interesting evolution in service patterns. There's a good talk by Jon Moore - Hypermedia APIs worth watching, this got my interest but fell down at the first hurdle (this one).


GET and POST have a clear content-neutral rationale. GET is to retrieve the content of an URL in a way that is safe to repeat and possibly cache. POST is to do something in a way that is not safe to repeat, execute speculatively, or cache.

There was no similar rationale for PUT or DELETE. They are both completely covered by POST. Creating or destroying a resource are operations that are not safe to repeat, not safe to execute speculatively, and should not be cached. There are no additional special semantics needed for them.

So basically there is no benefit.

  • 26
    Although POST covers PUT and DELETE, I can still see the benefit of having separate methods. All of them are covered in HTTP specification and their usage is encouraged in REST.
    – FilipK
    Commented Oct 13, 2011 at 13:23
  • 11
    @David: That would be a feature. Commented Oct 13, 2011 at 15:42
  • 18
    The rationale is that POST and DELETE have different -- almost opposite -- meanings. You claim that POST completely covers DELETE, yet POST is not idempotent and DELETE is. How do you explain that? w3.org/Protocols/rfc2616/rfc2616-sec9.html Commented Sep 17, 2013 at 18:27
  • 15
    Clever analogy, but you're re-defining what "covers" means. In your original answer, you mean "covers" as in, "supports all of the same use cases". Here you are redefining "covers" to mean some sort of taxonomical relationship. Let's cut through language: POST does not support the same use cases as DELETE due to the difference in idempotence. GET does not support the same use cases as DELETE due to the different semantics. Support for DELETE would increase user agent functionality. Commented Sep 17, 2013 at 18:53
  • 16
    I disagree with this answer. POST is not idempotent which is why when you click "back" in your browser, it will display an ugly page that says the form needs to be resent. However, had it been a PUT, it could safely resend the PUT request to display whatever page you should get. Provided of course one does not mess up the API by creating a sort of DELETE /resource/latest.
    – arg20
    Commented Aug 20, 2014 at 2:54

My understanding is that browsers don't know what to do once they send a PUT or a DELETE. A POST will redirect to an appropriate page usually, but PUT and DELETE typically don't. This makes them appropriate for calling via ajax or a native program, but not from a web browser form.

I can't hind it right now, but I remember reading one of the html5 mailing lists when they were discussing this.

  • 7
    Is there a reason that PUT and DELETE can't or don't redirect the same way as POST?
    – Ryan H
    Commented Jun 8, 2012 at 0:03
  • 3
    @maxpolun This is probably the mailing list your are referring to: lists.w3.org/Archives/Public/public-html-wg-issue-tracking/… Commented Aug 2, 2012 at 5:22
  • 3
    @RyanH There is not. Every app I have encountered that sends a delete request will reply with a redirect to the index.
    – Qwertie
    Commented Aug 28, 2018 at 1:06


I think it's worth mentioning the first appearance of HTML forms in RFC1866 (Section 8.1). Here the method attribute is defined as the following:

            selects a method of accessing the action URI. The set of
            applicable methods is a function of the scheme of the
            action URI of the form. See 8.2.2, "Query Forms:
            METHOD=GET" and 8.2.3, "Forms with Side-Effects:

Further explanations are located in Section 8.2.2 - GET and Section 8.2.3 - POST

Keep in mind, that HTML 2.0 (Nov. 1995) was specified before HTTP 1.0 (May 1996). So everybody used HTTP only with GET (as of HTTP 0.9) or with the extension POST. But only a few web servers supported PUT and DELETE (like stated in the HTTP 1.0 Appendix).


If you think about how Berners-Lee's development of the semantic web could have evolved it seems clear that it went from actual problems to a general concept

  1. First he wanted to share documents. Therefore he needed markup.
  2. Then he wanted to query databases for content, so he needed forms.
  3. Then he wanted to put new data into the database. So he used forms with GET and POST.

After that he may have realized that you could do every CRUD operation on data from remote, so HTTP was extended but never HTML because it was too late (only a few servers supported the new CRUD operations in 1996).


Get and post are are formats of transmitting the the data of the request.

I suppose you are asking about making form submission into a RESTFUL service. But it does not make sense to change the http request standard to make assumptions the purpose of the http request. Information of about the purpose that the request fills is best handled in the input fields.

Having an address and get and post allows the server to interpret the request and it's input values correctly. From there the input values allow you to make open ended requests to the server and do what ever you want. For example, you can have a field whose values are "put" and "delete"

  • 6
    -1 "Get and post are are formats of transmitting the the data of the request." No, they are HTTP methods, not "formats". Commented Sep 17, 2013 at 18:31

Just throwing out a wild guess, but probably because HTTP isn't terribly good with access control at the best of times, and the last thing everyone needs is even more ways for malicious URLs to compromise a poorly secured website and/or application.

HTTP isn't really a good protocol for file transfers other than downloading from server to client. Use FTP - or better yet, SFTP.

  • 13
    Security has no bearing on this. You can still make PUT/Delete requests via HTTP. curl --request PUT http://A.B.c/index The question is why can you access these commands via HTML. Commented Oct 13, 2011 at 14:40
  • 8
    -1 Wild guesses are generally not helpful on SO. Commented Sep 17, 2013 at 18:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.